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Maintenance  of  complex  systems  such  as  ship  Dropul sion/gas  turbine  plants 
poses  serious  human  factors  problems  for  the  maintained.  Gas  turbine 
plants  typically  require  a  team  of  maintainers  to  work  with  each  other 
on  different  aspects  of  a  common  problem.  This  paper  presents  a  model -based 
approach  for  identifying  problem  areas  resulting  from  excessive  workloads. 
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and  inadequate  handling  of  contingency  situations  from  a  maintainability  view¬ 
point.  This  approach  relies  on  modelling  human  behavior  (i.e.,  actions, 
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tations.  It  is  shown  that  within  this  framework,  it  is  possible  to  (a)  identify 
procedural  inconsistencies  and  ambiguities  that  may  impair  human  performance; 

(b)  explicitly  model  contingency  handling  procedures;  (c)  compute  instantaneous 
and  sustained  task-related  workload;  and  (d)  develop  guidelines  for  determining 
where  aiding,  automation  or  task  reallocation  may  be  warranted.  The  approach 
along  with  illustrative  examples  is  presented  within  the  context  of  a  selected 
problem  area  associated  with  the  maintainability  of  gas  turbine  propulsion 
systems. 
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ABSTRACT 


Maintenance  of  complex  systems  such  as  ship  propulsion/gas  turbine  plants 
poses  serious  human  factors  problems  for  the  maintainers.  Gas  turbine 
plants  typically  require  a  team  of  maintainers  to  work  with  each  other  on 
different  aspects  of  a  common  problem.  This  paper  presents  a  model-based 
approach  for  identifying  problem  areas  resulting  from  excessive  workloads, 
and  inadequate  handling  of  contingency  situations  from  a  maintainability 
viewpoint.  This  approach  relies  on  modelling  human  behavior  (i.e., 
actions,  decisions,  responses  to  specific  events)  within  Modified  Petri-net 
representations.  It  Is  shown  that  within  this  framework,  it  is  possible  to 
(a)  identify  procedural  Inconsistencies  and  ambiguities  that  may  Impair 
human  performance;  (b)  explicitly  model  contingency  handling  procedures; 

(c)  compute  Instantaneous  and  sustained  task-related  workload;  and 

(d)  develop  guidelines  for  determining  where  aiding,  automation  or  task 
reallocation  may  be  warranted.  The  approach  along  with  illustrative 
examples  Is  presented  within  the  context  of  a  selected  problem  area 
associated  with  the  maintainability  of  gas  turbine  propulsion  systems. ( 


1. 


INTRODUCTION 


Propulsion  and  power  plants  today  often  are  large  and  complex.  Their 
control  and  maintenance  involves  critical  coordination  among  the 
operators/maintainers  and  complex  human-plant  interaction.  These  plants 
(e.g.,  shipboard  propulsion  systems,  nuclear  power  plants)  are  typically 
maintained  by  a  team  of  noncol located  maintalners  that  at  all  times  have  to 
be  aware  of  each  other  roles  and  safety  requirements.  Two  main 
characteristics  make  propulsion  plant  maintenance  particularly  difficult: 
first,  the  propulsion  plant  consists  of  distributed  subsystems;  second, 
maintenance  of  these  systems  is  largely  a  decentralized  operation.  A 
distributed  system  Is  characterized  by  physical  components  that  are  not 
collocated  along  the  information  flow  path.  In  a  decentralized  operation, 
local  control  and  decision  functions  are  performed  by  independent 
components/operators.  In  other  words,  there  are  multiple  loci  of  decision 
and  control  In  performing  overall  system  maintenance.  In  sharp  contrast, 
centralized  systems  consist  of  system  operation  and  control  processes  that 
share  a  common,  deterministic  view  of  the  state  of  the  entire  system.  In  a 
decentralized  system,  the  various  components/operation  are,  at  best,  only 
loosely-coupled.  Consequently,  human-machine  communication  and  inter-human 
coordination  are  subject  to  both  time  delays  and  errors. 

Instances  of  progress  In  decentralized  control  systems  include  advances  in 
automation  technology  (Avizlenis,  1978;  Lee,  1981;  Perkins  and  Sargent, 
1982)  and  control  theory  (Athans,  1978;  Roffel  and  Rijnsdorp,  1982).  Yet, 
surprisingly  few  studies,  relatively  speaking,  have  focused  on  human 
supervision,  control,  and  maintenance  of  these  systems.  Johannsen  (1981) 
explored  the  concept  of  supervisory  fault -management  aids  for  decentralized 
systems.  Froquer  and  Meljer  (1980)  and  Bastl  and  Felkel  (1981) 
investigated  the  use  of  cause-consequence  trees  for  Interactive  on-line 
alarm  monitoring  systems.  Sheridan  (1981)  and  Johnson  and  Rouse  (1982) 


summarized  and  classified  generic  human  errors  in  the  process  plant 
environment.  These  and  other  earlier  studies  (e.g.,  Williams,  et  al., 
1982;  Report  of  the  President's  Commission  on  the  Accident  at  Three  Mile 
Island,  1979)  have  shown  that  there  are  serious  human-related  problems 
associated  with  the  maintenance  of  decentralized  systems  (i.e.,  systems 
consisting  of  spatially  separated  but  functionally  interconnected 
elements). 

Traditional  attempts  to  evaluate  and  improve  human  task  performance  have 
focused  on  centralized  systems  (e.g.,  electronics  and  aircraft) 
characterized  by  rapidly  changing  subsystem  states.  Consequently,  the 
maintenance  of  these  systems  (e.g.,  electronic  systems)  has  seen 
significant  improvements  with  the  incorporation  of  automated  test  equipment 
and  on-line  maintainability  aids.  On  the  other  hand,  problems  unique  to 
the  management  and  control  of  decentralized  systems,  while  generally 
recognized,  have  yet  to  be  investigated  by  the  research  community. 
Consequently,  the  lack  of  progress  in  maintenance  of  these  systems  does  not 
come  as  a  total  surprise.  Specifically,  there  are  two  main  causes  of  this 
lack  of  progress  that  can  be  readily  identified.  The  first  is  that 
maintenance/maintainablllty  aiding  technology  from  centralized  systems  does 
not  directly  lend  Itself  to  decentralized  systems  because  the 
characteristics  of  the  two  are  quite  different.  A  comparison  of 
power/propulsion  plants  and  electronic  system  characteristics  (see  Table  1) 
readily  shows  that  the  operational  complexity  of  the  former  generally 
exceeds  that  of  the  latter.  The  second  reason  is  associated  with  the 
difficulty  in  Identifying  and  quantifying  maintenance  and  maintainability 
related  problems  arising  from  poor  definition,  incomplete/imprecise 
description,  and  suboptimal  assignment  of  tasks. 

In  light  of  the  foregoing,  it  is  our  opinion  that  to  improve  propulsion 
plant  maintainability  It  Is  essential  to  first  recognize  the  critical 
differences  between  power/propulsion  (mechanical)  systems  and 


electronic/electrical  systems  (Table  1).  We  believe  that  these  differences 
result  in  distinctively  different  maintenance  practices  which  in  turn  give 
rise  to  significantly  different  human-related  maintainability  problems.  It 
appears  from  a  review  of  these  two  classes  of  systems  that  the  differences 
are  by  and  large  due  to  the  different  requirements  imposed  on  the 
maintainer-equipment  interface  by  the  external  environment.  Table  2 
presents  a  comparison  of  the  characteristics  of  electronic  systems  and 
propulsion  plant  maintenance  operations.  These  differences,  especially  as 
they  relate  to  procedural  and  team  coordination  aspects,  contribute  to  the 
unique  human  related  problems  associated  with  decentralized  system 
maintenance  and  maintainability. 

In  so  far  as  the  identification  and  analyses  of  maintainability  problems  is 
concerned,  traditional  human  factors  and  reliability  engineering  methods 
may  be  used  for  collecting  and  correlating  human  performance  data 
associated  with  specific  tasks.  However,  it  is  not  unusual  to  find  that 
both  the  definition  and  conduct  of  task  analyses  often  varies  from 
organization  to  organization.  Further,  the  various  types  of  task  analyses 
that  can  be  performed  are  generally  specific  to  the  functions  analyzed  by 
these  methods.  Regardless  of  the  specific  approach,  there  are  usually  four 
key  concerns  that  complicate  task  analyses: 

(1)  Accurately  defining  each  level  of  the  performance 
hierarchy. 

(2)  Determining  the  specific  level  in  the  hierarchy  at  which 
to  collect  data  (e.g.,  performance  cues,  associated 
training  problems,  etc.)  for  performance  diagnosis. 

(3)  Determining  the  various  types  of  data  that  should  be 
collected  to  aid  in  performance  diagnosis. 

(4)  Interrelating  specific  communication  and  coordination 
requirements  and  expected  behaviors  associated  with  each 
typical,  multi-person  task. 


TABLE  1 


COMPARISON  OF  ELECTRONIC  SYSTEMS  AND 
PROPULSION  PLANT  CHARACTERISTICS 


ELECTRONIC 

POWER/PROPULSION 

SYSTEM  ATTRIBUTES 

SYSTEMS 

PLANT 

.  CONFIGURATION 

CENTRALIZED 

DECENTRALIZED 

.  SIZE 

SMALL 

LARGE 

.  RELIABILITY 

CONSISTENT  (UNIFORM) 

LESS  CONSISTENT 
(VARIABLE) 

.  PROCESS  COMPLEXITY 

LOW 

HIGH 

.  SYSTEM  LAG 

SHORT 

LONG 

.  PHYSICAL  LAW 

LINEAR,  DECOUPLED 

NONLINEAR,  COUPLED 

.  ACCURACY 

QUANTITIVE 

MORE  OR  LESS 
QUALITATIVE 

.  ENVIRONMENTAL  DISTURBANCES 

WELL-KNOWN 

NOT  WELL-KNOWN 

.  PHYSICAL  VARIABLE 

SMALL 

LARGE 

.  OBSERVATION  OF  STATE  VARIABLES 

DIRECT 

INDIRECT 

TABLE  2 


COMPARISON  OF  ELECTRONIC  SYSTEMS 
AND  PROPULSION  PLANT  MAINTENANCE 


MAINTENANCE-RELATED 

ATTRIBUTES 

ELECTRONIC 

SYSTEMS 

POWER/PROPULSION 

PLANT 

.  PROCEDURE  STANDARDIZATION 

HIGH 

LOW 

.  OPERATION  KNOWLEDGE 

LOW 

HIGH 

.  TEAM  COORDINATION 

RARELY  REQUIRED 

FREQUENTLY  REQUIRED 

.  PERSONNEL  TRAINING 

HIGHLY  CONSISTENT 

LESS  RIGOROUS 

.  HUMAN-EQUIPMENT  INTERFACE 

HUMAN-ENGINEERED 

NOT  HUMAN- 
ENGINEERED 

.  DIAGNOSTIC  FEEDBACK 

ATE/BITE  AVAILABLE 

ATE/BITE  NOT 
AVAILABLE 

.  SAFETY  IMPACTS 

LOW 

HIGH 

.  SERVICE  COST 

'  LOW 

HIGH 

.  HUMAN  ERROR  COSTS 

LOW 

HIGH 

In  the  literature,  there  are  at  least  six  task  analysis  methods,  each  based 
upon  a  different  aspect  of  the  operator  and  task:  (1)  mission  objectives, 
(2)  behavioral  analyses,  (3)  information  processing,  (4)  decision 
paradigms,  (5)  subject  matter  structures,  and  (6)  vocational  schemata. 
These  methods  employ  one  of  many  formal  or  informal  procedures  typically 
with  somewhat  different  objectives,  but  usually  with  approximately 
identical  limitations  in  terms  of  their  diagnosticity,  versatility,  and 
ease  of  application. 

Another  analysis  method,  link  analysis  (Haygood,  et  al.,  1964;  Cullinane, 
1977,  Bonney,  1977),  is  a  global  method  that  is  useful  for  (a)  improving 
interface  design  and  (b)  diagnosing  to  a  limited  extent  the  various  causes 
of  inadequate  human  performance  stemming  from  inadequate  interface  design. 
Link  analysis  consists  of  documenting  each  interaction  among  components 
(e.g.,  data  entry  devices,  dials,  crew  members,  etc.)  over  the  scenario 
time  line.  Its  typical  output  consists  of  optimized  layouts  of  panels  and 
configurations  of  work  spaces .  The  main  limitation  of  link  analysis  is 
that  since  its  output  is  purely  a  frequency  plot,  it  cannot  explicitly 
represent  the  operational  sequence  that  led  to  a  specific  frequency 
distribution.  Further,  link  analysis  requires  observing  the  performance  of 
a  task  in  an  actual  work  setting  or  at  least  having  access  to  the  work 
setting  and  a  procedure  manual,  neither  of  which  may  always  be  possible. 

In  sum,  link  analysis  is  supplementary  to  task  analysis,  and  can  be  viewed 
as  one  method  for  using  the  results  of  task  analysis  to  specify  the 
plausible  sources  of  man-machine  Interface  problems  and  possible  means  for 
rectifying  them. 

Graphical  Evaluation  and  Review  Technique  (GERT)  is  another  class  of  models 
that  has  been  used  extensively  In  operator  activity  analyses.  This 
procedure  combines  flowgraph  theory,  moment  generating  functions  and 
Program  Evaluation  and  Review  Technique  (PERT)  to  obtain  a  solution  to 


stochastic  problems  In  task  representation  (Prltsker  and  Happ,  1966).  The 
GERT  transaction-flow  representation  method  Is  a  general  network-based 
approach  that  starts  with  task-paradigm  development  to  Identify  the 
subprocesses  and  the  Interactions  among  them.  Abstraction  of  the  process 
dynamics  and  interactions  then  leads  the  way  toward  simulation  techniques 
and  synthesis  of  submodels.  The  basic  elements  of  the  GERT  networks 
Include  logical  nodes,  probabilistic  activity  "realization,"  and  activity 
"transmittance"  parameters  (Whitehouse,  1973).  Efforts  have  been  made  by 
several  researchers  to  combine  the  network  approaches  with  other 
disciplines  such  as  control  theory  (Seifert,  1979;  Kraiss,  1981),  queueing 
theory  (Pritsker,  1979),  and  knowledge-based  production  systems  (Doring  and 
Knauper,  1982).  The  technique  is  quite  general  and  capable  of  representing 
various  task  situations.  The  main  limitation  of  the  GERT-type  network  is 
that  since  the  activity  attributes  are  assigned  within  each  node,  it 
frequently  gets  involved  with  complex  connections  and  branching  of  nodes 
that  introduces  rigidity  in  model  structure,  constraints  on  model  analyses, 
and  high  demands  on  input  data. 

In  summary,  a  generic  approach  for  task  analysis  is  required  for 
characterizing  and  analyzing  complex  situations  involving  multiple  actors 
collectively  engaged  in  a  cooperative  task. 

To  this  end,  the  purpose  of  this  study  is  to  develop  a  generic  approach  for 
(1)  modelling  and  analyzing  multi-person  maintenance  tasks  from  the 
viewpoint  of  identifying  potential  human-related  maintainability  problems, 
and  (2)  developing  guidelines  for  alleviating  their  impact  on  current 
systems  and  circumventing  such  problems  in  future  systems. 

At  the  heart  of  our  approach  is  a  Modified  Petri  Net -based  characterization 
of  multi -person  maintenance  task.  We  use  this  representational  framework 
in  developing  task  information  flow  models  capable  of  explicitly 
characterizing  individual  activities,  events  and  contingencies  resulting 
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from  the  environment  or  arising  as  a  result  of  human  error.  Subsequent 
simulation  and  analysis  of  this  network  In  terms  of  Identifying  possible 
concurrencies  and  alternate  ways  of  doing  the  task  allows  us  to  identify 
procedural  Inconsistencies,  ambiguities,  resource  conflicts,  and  operator 
workload,  l.e.,  all  human-related  maintainability  problems.  We  attempted 
to  verify  some  of  our  findings  to  the  extent  possible  against  historical 
data  bases  (e.g.,  3M)  and  via  expert  elicitation.  In  the  next  phase  of 
this  study,  we  intend  to  collect  performance  data  from  simulated  exercises 
at  Great  Lakes  Training  Center. 

In  subsequent  sections  of  this  report,  we  summarize  the  key  elements  of  our 
overall  approach.  In  chapter  2  we  present  the  basis  of  our  modelling 
approach,  maintainability-related  problem  selection  and  characterization. 
In  chapter  3  we  introduce  the  notion  of  how  the  model  can  be  used  as  a 
guide  to  identifying  operator  workload  and  explain  the  approach  via  an 
illustrative  example.  In  chapter  4,  we  present  the  key  elements  of  the 
software  that  we  developed  in  support  of  our  analysis.  In  chapter  5  we 
summarize  our  preliminary  findings  from  analysis  of  Navy  3M  data  bases. 
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MODIFIED  PETRI  NET  (MPN)-BASED  TASK  MODELLING 


2.1  Modified  Petri  Net  (MPN)  Representation 

The  analysis  of  multi-person  maintenance  tasks  is  based  on  a  Petri  net 
model -based  framework.  A  Petri  net  is  an  abstract,  formal  model  of 
information  flow.  The  properties,  concepts,  and  techniques  of  Petri  nets 
are  being  developed  in  a  search  for  natural,  simple,  and  powerful  methods 
for  describing  and  analyzing  the  flow  of  information  and  control  in 
systems,  particularly  systems  that  may  exhibit  asynchronous  and  concurrent 
activities.  The  major  use  of  Petri  nets  has  been  the  modelling  of  systems 
of  events  in  which  it  is  possible  for  some  events  to  occur  concurrently, 
but  there  are  constraints  on  their  occurrence,  precedence,  and  frequency. 

Petri  nets  have  been  used  in  the  studies  of  parallel  computation  (Miller, 
1973),  multiprocessing  (Agerwala,  1979),  computer  system  modeling 
(Peterson,  1980),  knowledge  representation  (Zisman,  1978),  as  well  as  human 
processes  (Schumacker  and  Geiser,  1978).  The  properties  along  with  an 
example  of  a  Petri  net  are  given  in  Appendix  A. 

Petri  nets  have  been  adapted  and  modified  in  this  study  in  an  attempt  to 
overcome  either  a  specific  shortcoming  or  eliminate  certain  features  that 
can  potentially  introduce  unwarranted  complexity  in  the  computer 
implementation  of  the  net.  For  the  sake  of  clarity,  we  will  refer  to  the 
modified  net  as  modified  Petri  nets  (MPN).  The  specific  constraints  and 
additions  that  we  have  introduced  in  the  Petri  net  are  given  below,  along 
with  a  brief  discussion  of  each. 


10 


(1)  Safeness;  Limitations  on  Number  of  Tokens.  A  Petri  net  is 
safe  if  all  places  in  the  net  are  safe.  A  place  in  a  Petri 
net  is  safe  if  the  number  of  tokens  in  that  place  never  exceed 
one.  In  our  implementation  we  limit  the  number  of  tokens  in 
any  place  to  one  by  disallowing  Petri  net  structures  that 
violate  this  requirement. 

(2)  Completion  Event.  In  our  interpretation  of  Petri  nets,  places 
are  used  to  represent  activities.  These  activities  when 
completed  generate  an  internal  completion  event  that  may  be 
used  as  one  of  the  requirements  for  firing  a  transition  and 
moving  the  token  out  of  the  input  place  to  the  output 
place(s). 

(3)  Hierarchical  Expansion  of  a  Place.  A  single  place  in  a  Petri 
net  can  be  expanded  as  a  Petri  net,  starting  at  a  place  and 
ending  at  a  place.  This  expansion  is  a  deeper  level  of  the 
net  (i.e.,  a  greater . degree  of  detail).  Consider  place  Pj 

that  is  expanded  into  the  subnet  P^  . Pln  in  the  figure 

below 


When  a  token  comes  into  P^,  a  token  is  immediately  placed  in 
The  token  in  P^  is  then  propagated  throughout  the  lower 
level  subnet  P^  ...  P^n  until  it  reaches  the  "dummy"  place 
p^n.  As  soon  as  the  token  reaches  Pjn,  the  internal 
completion  event  for  the  activity  in  P1  is  set  and  the  token 
is  removed  from  the  "dummy"  place  P^n. 


11 


(4)  Aborting  an  Activity.  An  output  transition  associated  with  a 
place  need  not  fire  after  the  occurrence  of  the  internal 
completion  event  for  that  place.  It  can  fire  "prematurely," 
that  is,  before  the  occurrence  of  the  internal  completion 
event.  In  this  case,  an  abort  is  said  to  have  occurred.  If 
the  input  place  is  expanded  as  a  subnet,  all  tokens  in  that 
subnet  must  be  removed  when  the  token  in  the  parent  place  is 
removed.  This  process  of  removing  any  lower  level  tokens 
during  an  abort  involving  a  hierarchical  expansion  will  be 
referred  to  as  "vacuuming." 

(5)  Proper  Termination.  Petri  nets,  in  general,  are  not  properly 
terminating.  We  stipulate  that  for  our  MPN  to  be  properly 
terminating,  it  must  reach  a  final  marking*, 

in  which  only  one  token  remains  in  the  net  and  that  it  be  in 
the  final  place.  Thus,  a  properly  terminating  MPN  guarantees 
that  a  final  marking  will  be  reached.  We  impose  this 
restriction  on  our  model  for  ease  of  implementation  and 
interpretation. 

2.2  Task  Performance  Interpretation  Within  MPN  Modelling  Paradigm 

The  advantages  and  disadvantages  of  Petri  Nets,  in  general,  and  MPN,  in 
particular,  have  been  discussed  at  length  in  the  previous  sections.  In 
this  section,  the  specifics  of  MPN  in  human  performance  modelling  are 
discussed.  The  first  requirement  Is  to  develop  a  convention  for 
characterizing  tasks  within  an  MPN.  To  this  end,  the  following  convention 
is  adopted  within  the  MPN  framework. 


T 


A  marking  is  the  set  of  all  places  occupied  by  tokens  at  any  point  in  time. 
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The  propositions  that  are  evaluated  to  determine  when  a  transition  should 
fire  are  one  of  the  following  simple  Boolean  expressions  that  is  repeatedly 
evaluated  until  true: 

(1)  I 

(2)  E 

(3)  IA  E,  IA  E 

When  I  is  not  "anded"  in  an  expression  in  the  above  propositions  as  with  E 
or  I  A  E,  we  have  a  situation  where  the  transition  may  fire  before  normal 
completion  of  the  ongoing  activities,  producing  an  abort.  Such  a 
transition  can  be  termed  a  "possible  abort  transition." 

MPN-Based  Performance  Evaluation 

Within  the  selected  event-driven  framework  several  types  of  performance 
measures  can  be  defined.  In  addition  to  the  conventional  product  measures 
(i.e.,  outcome),  several  process  measures  can  be  defined.  These  include: 

(1)  Event-related  measures. 


(a)  Correct  recognition  of  an  event  in  terms  of  correct 
subsequent  action. 

(b)  Missed  detection/recognition  of  an  event  (i.e.,  no  action 
taken  when  required). 

(c)  Failure  to  perform  a  required  activity  or  subtask  in  a 
procedural  sequence. 

(d)  Introduction  of  an  extraneous  activity. 


(2)  Time-based  measures. 


(a)  Time  to  perform  a  required  activity. 

(b)  Time  to  perform  a  total  task. 

(c)  Time  to  respond  to  an  action-necessitating  event. 

The  above  measures  are  diagnostic  in  reconstructing  “what  went  on"  in 
actual  task  performance.  Some  of  these  measures  are  objective,  that  is, 
they  can  be  measured.  Others  have  to  be  subjectively  elicited  either  post 
hoc  or  at  suitably  selected  interim  points  in  actual  task  performance.  In 
the  latter  case,  the  prescriptive  Petri  net  model  can  be  used  as  a  guide  to 
the  performance  elicitation  process. 

2.3  Suitability  of  MPN  for  Human  Behavior/Performance  Modelling 

Several  key  features  make  Petri  nets  and,  in  particular,  modified  Petri 
nets  (MPNs )  an  appealing  framework  for  modeling  multi-person  maintenance 
tasks.  Mostly  these  appealing  characteristics  arise  from  the  ability  of 
MPNs  to  represent: 

(1)  Sequential /parallel  processes. 

(2)  Asynchronous  events. 

(3)  Interactions  between  concurrent  processes. 

(4)  Temporal  order  and  propagation  effects. 

(5)  Dynamic  flow  of  information. 

(6)  Varying  degrees  of  detail  within  a  hierarchical  structure. 

These  features  can  be  exploited  in  human  task  performance  modelling  in 
several  ways: 

(1)  Representation  of  expert  behavior  including  heuristics  and 
strategies  (prescriptive  model  of  task  performance). 
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(2)  Representation  and  monitoring  of  novice  behavior  in  terms  of: 


(a)  Competition  among  actions  —  doing  one  thing  inhibits 
doing  another. 

(b)  Cooperation  among  actions  —  operations  associated  with 
one  action  are  suspended,  aborted,  or  modified  to 
accommodate  another. 

(c)  Slips  of  performance  —  components  of  one  action  sequence 
are  intermixed  with  components  of  another.  Sequence 
steps  may  be  omitted,  out-of-sync,  or  inadvertently 
isolated. 

There  are  several  specific  potential  advantages  in  employing  Petri  nets  for 
describing  human  expert/novice  behavior.  First,  the  hierarchical 
decomposition  of  tasks  into  subtasks  makes  it  convenient  to  focus  on 
human-related  problem  areas  at  any  appropriate  level  of  abstraction. 
Second,  the  token  propagation  patterns  can  be  used  to  create  procedural 
templates  and  loci  of  potential  slips  and  misses.  Third,  feedback  and 
coaching  can  be  provided  to  the  operator  by  Insertion  of  missing  elements 
(e.g.,  activities,  action-related  events  that  were  inadvertently  left  out 
in  the  task  description  and  associated  procedures).  Finally,  Irrelevant 
elements  can  be  deleted  from  task  descriptions. 

Petri-net  representation  of  multi-person  maintenance  tasks  lends  itself  to 
both  optimization  and  revision  of  maintenance  procedures  (as  originally 
conceived  by  the  designer  or  instructor  without  altering  the  maintenance 
task  itself).  The  optimization  process  consists  of  first  representing  the 
task  in  MPN  formalism  and  then  reducing  the  net  via  network  manipulation 
rules  subject  to  system,  task  and  environmental  constraints.  The  reduced 
net  can  then  be  used  to  write  revised  specifications  for  review  and 
revision/certification  by  the  system  designer  (see  Figure  1). 
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OBJECTIVE 


FIGURE  1. 

HPN-BASED  MAINTENANCE  PROCEDURE  REVISION/OPTIMIZATION 


(1)  Places  are  associated  with  human-related  processes  or  activities. 

(2)  Transitions  are  associated  with  propositions  involving  the 
decision  to  change  from  one  activity  to  another. 

Places.  Human-related  processes  or  activities  may  be  of  two  kinds: 
passive  (static)  or  active  (dynamic).  Passive  processes  involve  wait 
states,  such  as  monitoring  a  CRT  for  a  possible  error  message  or  waiting 
for  a  phone  call.  Active  or  dynamic  processes  involve  activities  that  have 
a  beginning  and  an  end  (i.e.,  completion)  such  as  reporting  the  position  of 
an  oil  leak  over  an  intercom. 

Transitions.  It  is  worth  recalling  that  within  a  PN  framework,  transitions 
are  enabled  when  all  input  places  have  tokens;  however,  exactly  when  a 
transition  fires  is  not  defined  within  the  PN  formalism.  To  this  end,  we 
can  associate  the  firing  of  transitions  to  specific  propositions  that  have 
to  be  repeatedly  evaluated  once  all  input  places  to  the  transition  have 
tokens.  This  evaluation  continues  until  the  transition  fires.  These 
propositions  are  Boolean  expressions  involving  various  conjunctive  and/or 
disjunctive  combinations  of  two  types  of  primitives:  (a)  normal  internal 
completion  (I),  and  (b)  external  stimulus  or  condition  (E). 

(a)  Normal  Completion  Event  (I).  Normal  completion  is  an  internal 
event  associated  with  the  completion  of  activities  associated  with 
all  active  places  input  to  the  transition. 

(b)  External  Event  (E).  An  external  event  can  be:  (a)  an  external 
stimulus  (I.e.,  a  transient  or  momentary  event  external  to  the 
primary  ongoing  activities  associated  with  all  places  input  to  the 
transition),  (b)  a. prevailing  condition  associated  with  the  real 
world  environment  or  state  of  the  world  model  at  the  moment  when 
the  real  world  or  its  model  is  "sampled." 
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The  net  manipulation  rules  include: 

(1)  Eliminating  a  place  (i.e.,  activity  or  sub-task)  if  it  does 
not  lead  to  a  subsequent  level  of  performance  and/or  a 
maintenance  goal. 

(2)  Combining  places  (i.e.,  activities)  if  two  or  more  places  have 
the  same  output  events.  All  rules  applicable  to  the  original 
events  can  then  be  applied  to  the  new  event. 

(3)  Combining  events  (i.e.,  propositions)  into  a  single  event 
(i.e.,  proposition)  if  two  or  more  events  have  the  same  input 
and  output  places. 

The  MPN  model  can  be  used  for  both  descriptive  and  prescriptive  purposes, 
for  behavior  and  performance  measures,  to  represent  both  the  structure  as 
well  as  the  input-output  of  task-related  activities  and  processes.  The 
prescriptive  MPN  can  be  used  to  characterize  the  Engineering  Operations 
Systems  Sequence/Emergency  Operations  Casualty  Control  (EOSS/EOCC) 
instructions/procedures.  The  descriptive  MPN,  when  compared  with 
prescriptive  MPN,  can  provide  templates  for  operator  slips  and  errors. 
Both  behavior  and  performance  can  be  evaluated  within  this  descriptive  MPN. 
The  behavioral  aspect  of  the  descriptive  MPN  models  what  the  operator's 
action  is;  whereas,  the  performance  aspect  of  the  MPN  models  how  well  the 
action  is  performed.  Since  a  model  that  can  accurately  predict  behavior 
will  also  be  able  to  accurately  predict  performance,  but  not  vice  versa, 
the  behavioral  model,  in  general,  will  be  "stronger"  than  the  performance 
model . 

In  subsequent  sections,  a  representative  propulsion  system  maintenance  task 
that  leads  to  maintainability-related  human  factors  problems  is  presented 
along  with  a  detailed  analysis  using  Modified  Petri  Net  (MPN)  models. 


2.4 


Maintainability  Problem  Selection 


One  of  the  first  decisions  for  this  study  was  to  select  a  high-payoff 
system  and  problem  area  for  analysis  of  human-related  maintainability 
problems.  To  this  end,  the  following  criteria  were  employed  for  system  and 
subsystem  selection: 

(1)  The  selected  system  should  be  characteristic  of  current  and 
future  maintainability  requirements. 

(2)  The  selected  subsystem  should  require  event-driven  responses 
involving  concurrent  and  coordinated  maintainer/operator 
participation.  This  includes  recognizing  combinations  of 
manual /psychomotor,  rule-driven/pattern  matching  and 
problem-solving  behavior  on  the  part  of  the  operator. 

(3)  System  performance  should  impact  platform  mission  performance. 

(4)  Operating  procedures  for  the  system  and  subsystems  should  be 
sufficiently  complex  to  involve  the  human  performance  problems 
arising  from  (i)  inappropriate  task  assignments,  (ii)  task 
overload/underload,  and  (iii)  inadequate  procedural  and 
systems  knowledge. 

(5)  The  maintainability  procedures  associated  with  the  system 
should  be  such  that  a  diversity  of  outcomes  (both  optimal  and 
suboptimal )  can  result  from  them.  In  addition,  procedures 
should  be  sufficiently  complex  to  permit  operator-induced 
equipment  failure. 
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(6)  The  system  and  subsystems  should  be  amenable  to  being 
retrofitted  or  augmented  with  total /partial  function 
automation  or  equipment  operator/maintainer  aids. 

Interviews  with  supervisory  personnel  in  Navy  ships  maintenance  and 
evaluation  of  Navy  maintenance  requirements  and  activities  related  to  the 
selection  criteria  presented  above  resulted  in  one  prime  candidate  system: 
the  LM2500  Propulsion  Gas  Turbine  module  as  configured  for  the  DD963  class 
of  ship.  Specific  candidate  subsystems  included  the  Gas  Turbine  Module 
(GTM)  fuel  oil  system  and  the  lubrication  system.  The  LM2500  GTM  system 
was  selected  because  the  LM2500  Propulsion  Gas  Turbine  module  (GTM)  can  be 
found  on  three  classes  of  naval  combatants:  (1)  Spruance  (DD963)  class, 
(2)  Oliver  Hazard  Perry  (FFG  7)  class,  and  (3)  Pegasus  (PHM1)  class. 

Future  ship  classes  that  will  use  the  GTM  for  main  propulsion  are  the 
Ticonderoga  (CG  47)  class  currently  authorized  for  21  ships  through  FY  1986 
and  an  undetermined  number  of  undesignated  FFX  and  DDGX  vessels.  By  1988, 
it  is  reasonable  to  project  that  of  all  surface  combatants  (CG,  DDG,  DO  and 
FF)  48  percent  will  be  GTM  powered- and  that  92  percent  of  those  that  are  15 
years  old  or  newer  will  be  GTM  powered.  Of  all  GTM  powered  tonnage,  66 
percent  will  be  D0963  power  plant  configured.  In  light  of  the  above,  the 
DD963  GTM  is  preeminently  characteristic  of  both  current  and  future 
maintainability  requirements. 

The  GTM  is  the  prime  power  source  for  propulsion.  The  DD963  propulsion 
system  requires  4  GTM's.  Two  GTM's  power  each  of  the  ship's  two  propulsion 
shafts.  Failure  of  a  gas  turbine  and  any  of  its  major  subsystems  results 
in  a  direct  loss  of  propulsion  horse-power  capacity.  Supporting  the 
operation  of  the  gas  turbine  are  two  major  subsystems:  the  lubrication 
system  and  the  fuel  oil  system.  Both  function  continuously  during  power 
plant  operation. 


Consequently,  the  two  subsystems  selected  for  the  maintainability  study  are 
the  fuel  oil  system  and  the  lube  oil  system.  The  fuel  oil  system  is  more 
complicated  and  contributes  to  frequent  maintenance  problems.  However,  the 
problems  associated  with  the  lube  oil  system,  especially  the  main  reduction 
gear  lube  oil  system,  are  time-stressed  and  can  cause  greater  damage  to  the 
gas  turbine  plant,  often  leading  to  total  disruption  of  the  ship's 
propulsion  function.  Consequently,  since  the  lube  oil  system  poses  a  more 
severe  maintainability  problem  to  the  Navy  maintenance  personnel,  it  was 
selected  for  an  analysis  of  human-related  maintainability  problems.  A 
description  of  the  selected  maintenance  system  and  tasks  is  given  in 
Appendix  B. 


2.5  MPN-Based  Characterization  of  Selected  Maintainability  Problem 

The  problem  selected  for  analysis  concern s  the  crew  decision-making 
sequence  for  the  main  reduction  gear-related  lube  oil  problem.  This 
problem  requires  coordination,  communication,  and  Interdependent  decision¬ 
making  and  action  taken  between  the  Engineering  Officer  of  the  Watch  (C.00W) 
and  the  engine  room  operators  (ERQs).  In  the  following  paragraphs  the 
problem-handling  sequence  will  be  described  In  great  simplified  terms  from 
both  the  EOOW  and  ERO  perspectives. 

The  EOOW's  Perspective.  The  EOOW,  in  the  Central  Control  Station  located 
in  the  midsection  of  the  ship,  is  the  overall  supervisor  responsible  for 
monitoring  the  performance  of  the  propulsion  system,  supervising  and 
coordinating  with  the  watch  team  personnel,  and  making  timely  and  necessary 
decisions.  In  this  capacity,  one  of  the  systems  that  he  is  responsible  for 
is  the  engine  room  lubrication  oil  system.  (There  are  two  identical 
systems,  one  for  each  engine  room.)  The  information  and  communication 
resources  available  to  the  EOOW  are:  instruments  that  monitor  the  pressure 
in  the  main  reduction  gear  (MRG)  and  at  other  strategic  points  in  the 


propulsion  system,  sophisticated  display  systems  that  provide  the  operator 
with  status  and  malfunction  information  associated  with  the  propulsion 
system,  and  various  telephones  and  bi-directional  communication  facilities 
for  issuing  orders  and  receiving  reports. 

There  are  three  abnormality  conditions  that  require  prompt  and  sound 
decisionmaking  on  the  part  of  the  EOOW:  report  of  an  engine  room  fire,  a 
lube  oil  leak,  or  a  pressure  drop  on  the  MRG  lube  oil  pressure  gauge.  In 
the  following  paragraphs,  the  handling  of  each  of  these  conditions  from  the 
EOOW's  perspective  are  presented  along  with  an  explicit  characterization  of 
the  coordination  and  communication  between  the  EOOW  and  the  EROs. 

For  the  first  condition  (i.e.,  fire  reported),  the  EOOW  first  acknowledges 
the  receipt  of  the  report  using  his  communication  resources  and  informs  the 
engine  room  that  he  is  about  to  recommend  for  General  Quarters  (GQ).  GQ,  a 
subset  of  the  Emergency  Operations  and  Casualty  Control  [EOCC]  protocol,  is 
a  well -documented  and  rigorously  specified  emergency  control  procedure. 
The  EOOW  then  hears  the  engine  room  operator  acknowledge  this  report,  and 
indicates  his  intent  to  combat  the  fire.  If  the  fire  is  serious,  then  the 
Officer  of  the  Deck  (000),  the  Captain,  or  Commanding  Officer  may  initiate 
GQ  at  his  discretion.  The  full  resources  of  the  Engine  Room  and  the  EOOW 
are  marshalled  to  combat  the  fire.  The  complex  sequence  of  operations  that 
ensue  are  oversimplified  in  what  follows.  The  EOOW  proceeds  with  EOCC 
procedures  while  awaiting  the  next  report  from  the  engine  room.  If  the 
engine  room  operator  reports  that  the  fire  is  under  control,  the  EOOW  may 
recommend  to  cancel  GQ.  If,  on  the  other  hand,  the  engine  room  operator 
indicates  that  the  fire  is  out  of  control,  he  also  reports  that  engine  room 
personnel  are  evacuating,  and  supplies  the  names  of  the  evacuating 
personnel  to  the  best  of  his  knowledge.  At  this  time,  the  EOOW  makes  a 
specific  check  to  ascertain  that  all  personnel  that  he  had  sent  to  the 
engine  room  who  were  not  officially  on  watch  have  evacuated.  The  EOOW  then 
verifies  that  all  personnel  have  Indeed  evacuated,  and  proceeds  with  GQ. 


The  second  contingency  condition  is  the  receipt  of  a  lube  oil  leak  report. 
The  report  contains  both  the  location  and  the  approximate  magnitude  of  the 
leak.  The  EOOW  assimilates  this  information,  and  evaluates  whether  the  leak 
is  pre-fork  or  post-fork.  (Each  engine  room  has  two  lube-oil  pumps.  The 
oil  lines  emanating  from  each  pump  join  together  to  provide  a  common  feed. 
A  leak  before  this  junction  is  termed  'pre-fork';  a  leak  after  the  junction 
is  'post-fork'.)  If  the  leak  is  post-fork,  the  EOOW  apprises  the  engine 
room  of  this  fact  and  initiates  EOCC  by  securing  the  MRG.  If  the  leak  is 
pre-fork,  the  EOOW  starts  the  second  pump  first,  then  secures  the 
malfunctioning  pump,  simultaneously  informing  the  engine  room  of  his 
actions.  He  then  checks  the  pressure  on  his  gauge  and  verifies  that  it  has 
returned  to  normal.  At  this  point,  the  EOOW  can  direct  the  needed  repairs 
on  a  non-emergency  basis. 

The  third  possible  case  occurs  when  the  EOOW  observes  a  pressure  drop  on 
his  own  gauge.  He  verifies  the  drop  through  an  independent  source.  This 
may  require  the  watch  stander  in  the  engine  room  to  inspect  the  gauges  on 
the  equipment  itself.  Conversely,  a  dedicated  display  or  a  plasma  display 
may  be  used  to  provide  the  necessary  redundant  verification.  If  the  DDI 
reading  is  normal,  the  EOOW  calls  the  engine  room  and  requests  confirmation 
of  this  fact.  When  confirmation  is  received,  the  EOOW  calls  another 
department  (GSE)  to  have  the  meters  checked.  If  the  reading  is  abnormal, 
thus  verifying  the  drop,  the  EOOW  informs  the  engine  room  of  the  drop  and 
of  the  current  pressure  level.  If  the  engine  room  indicates  that  the 
situation  is  normal,  the  EOOW  contacts  GSE  as  above.  If  the  engine  room 
confirms  that  the  situation  is  abnormal,  the  EOOW  orders  an  investigation 
and  continues  to  monitor  the  pressure  on  his  gauge.  The  EOOW  knows  that 
the  engine  room  staff  will  check  the  unloader  valve  first  for  proper 
calibration.  If  the  unloader  is  incorrectly  set,  the  engine  room  personnel 


will  adjust  it.  With  this  adjustment,  the  EOOW  will  observe  the  pressure 
on  his  gauge  begin  to  climb.  He  announces  the  increasing  pressures 
(feedback)  over  his  communicator,  until  the  pressure  reading  is  normalized. 

Adjusting  the  unloader  is  a  procedure  that  takes  no  more  than  five  seconds. 
If  the  EOOW  does  not  observe  a  change  in  pressure  after  five  seconds  he 
may,  at  his  discretion,  send  additional  personnel  to  the  engine  room  to 
help  while  he  awaits  the  report  on  the  remainder  of  the  investigation. 
Eventually  the  EOOW  will  receive  a  report  on  the  discovery  of  a  leak  along 
with  its  location  and  approximate  magnitude.  If  a  leak  is  reported,  the 
subsequent  procedure  is  identical  to  that  associated  with  the  second 
condition  above  (i.e.,  report  on  a  lube  oil  leak  received  by  the  EOOW).  If 
the  report  indicates  that  no  leak  was  found,  the  EOOW  orders  the 
examination  of  other  possible  sources  of  the  problem  (e.g.,  meters, 
pressure  sensors,  etc.). 

In  each  of  the  above  cases,  the  final  step  involves  verification  of  normal 
operation.  When  normal  operation  is  verified ,  the  EOOW  resumes  his  watch, 
monitoring  the  various  gauges  on  .his  control  panel.  The  MPN  from  the 
EOOW's  perspective  is  given  in  Figure  2. 

Engine  Room  Staff  Perspective.  From  the  standpoint  of  the  engine  room 
staff,  there  are,  once  again,  three  events  that  force  them  to  make 
immediate  decisions  and  take  actions:  noticing  a  fire,  noticing  a  lube  oil 
leak,  or  receiving  an  order  from  the  EOOW  to  check  out  a  pressure  drop. 

If  a  fire  is  found,  the  engine  room  operator  immediately  reports  it  to  the 
EOOW.  When  the  EOOW  has  responded  and  informed  the  engine  room  that  he 
intends  to  initiate  GQ,  the  engine  room  operator  acknowledges  this  decision 
and  informs  the  EOOW  that  he  will  attempt  to  combat  the  fire.  The  engine 
room  staff  then  employs  the  fire-fighting  Twin  Agent  System  (TAS).  (TAS 
Includes  Purple  K,  an  agent  which  reduces  the  extent  of  fire  so  its  source 


FIGURE  2. 

PETRI  NETS  REPRESENTATION  OF  EOW  REACTION  SEQUENCE 
TO  LUBE*  OIL  PROBLEMS 
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Places:  Definitions 


Pg:  Monitor  MRG  Lube  Oil  Pressure  Gage 

n  -  Acknowledge  Fire  Report  and  Inform  Engine  Room  of  Initiation  of  GQ 
Wait 

Initiate  GQ 
Cancel  GQ 

Verify  Evacuation  of  Personnel 
Read  DDI  for  Authentication 

Inform  Forward  Engine  Room  of  Presure  Drop  (17  psi) 

Call  Engineering  Officer  Present,  Request  Confirmation 
Order  Investigation 
Wait  and  Monitor  Pressure 
Call  up  GSE  for  Meter/Digital  Checks 
Command  Correction 
Wait  for  Report  of  Investigation 
Order  Additional  Help  to  Engine  Room 
Hold 

Evaluate  Magnitude  and  Location  of  Leak 
Evaluate/Fix  Other  Causes  (Meters,  etc.) 

Start  New  Pump 
Inform  Forward  Engine  Room 
Inform  Forward  Engine  Room 
Secure  MRG  According  to  EOCC 
Secure  Old  Pump 
Check  Pressure 

Perform  Non-Emergency  Repair  Procedure 
•  •  • 

Evaluate  Normal  Operation 
itions:  Definitions 
Fire  Reported 

Engine  Room  Reports  that  Attempt  to  Combat  Fire  Will  be  Made 
Report  Fire  Under  Control 
Report  Out-of-Control;  Evacuating 
GQ  Cancelled 
GQ  Initiated 
Pressure  Drop  Observed 
Drop  Authenticated 
DDI  Reading  Normal 
Situation  Abnormal 
Situation  Normal 
Confirmation  Received 
Investigation  Ordered 
Pressure  Drop  =  0 
Pressure  Drop  i  0 
Reading  O.K. 


T^:  Call  Made 

T7ft:  Report  on  Existence/Location  of  Leak  Received 

Tfg:  Leak 

T ?n:  No  Leak 

T21 :  Pre-Fork  Leak 

T??:  Post-Fork  Leak 

Tpj:  Fixed 

Tp^:  New  Pump  Started 
Tpg:  Old  Pump  Secured 

Tp^:  Forward  Engine  Room  Informed  and  MRG  Secured  According  to  EOCC 

T27 :  Verify  Normal 

T23:  Non  Emergency  Repairs  Complete 

T^:  Abnormal 

T30 : 

T3j :  Leak  Reported 
T32^  Continue 


can  be  determined,  and  AFFF  [aqueous  film-forming  foam],  which  smothers  the 
reduced  fire  at  its  source.)  If  TAS  fails  to  bring  the  fire  under  control, 
the  operator  abandons  the  TAS,  heads  for  the  control  console,  and  reports 
to  the  EOOW  that  the  ft  re  is  out  of  control  and  all  engine  room  personnel 
are  in  the  process  of  evacuating.  He  also  supplies  the  names  of  the 
evacuating  personnel.  These  individuals  then  evacuate.  If  TAS  succeeds  in 
bringing  the  fire  under  control,  the  engine  room  operator  reports  this  to 
the  EOOW. 

If  a  leak  is  noticed,  the  engine  room  operator  reports  it  to  the  EOOW. 
Instructions  from  the  EOOW  can  require  the  engine  room  staff  to  commence 
EOCC  procedures  or  open  and  close  valves  as  part  of  the  procedure  for 
switching  on  one  lube  oil  pump  and  switching  off  the  other.  In  the  latter 
case,  the  engine  room  operator  proceeds  to  perform  the  necessary 
non-emergency  repair  functions. 

In  the  third  case,  the  EOOW  informs  the  engine  room  of  a  drop  in  observed 
pressure.  The  engine  room  operator  checks  the  pressure  and  confirms  or 
disconfirms  the  EOOW's  reading.  If  the  pressure  is  abnormal,  the  engine 
room  operator  is  ordered  to  investigate  the  cause.  The  engine  room 
operator  firsts  check  the  unloader.  If  the  unloader  is  poorly  aligned,  he 
proceeds  to  adjust  it  in  response  to  the  changing  pressure  readings 
announced  by  the  EOOW.  If  there  is  no  problem  with  the  unloader,  the 
engine  room  operator  starts  to  search  for  a  lube  oil  leak.  If  a  leak  is 
found  the  engine  room  operator  proceeds  as  in  the  preceding  paragraph.  If 
no  leak  is  found,  the  engine  room  operator  reports  this  to  the  EOOW.  The 
EOOW  then  orders  an  evaluation  of  other  possible  sources  of  the  problem 
(e.g.,  sensors).  Subsequent  to  traversing  any  one  of  these  possible  paths, 
the  engine  room  staff  is  informed  when  to  return  to  their 
standby /monitoring  watch  state.  The  MPN  from  the  Engine  Room  Staff 
perspective  is  shown  in  Figure  3. 
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Places:  Definitions 


Monitor  Engine  Room  and  Control  Panel 

Report  Fire  to  EOW 

Conduct  Fire-Fighting  with  TAS 

Report  Fire  Under  Control 

Report  Fire  Out  of  Control;  Evacuating 

Evacuate 

Report  Existence,  Location,  and  Magnitude  of  Leak 
Await  Order  to  Initiate  EOCC 
Adjust  Valve 
Secure  (from  EOCC) 

Perform  Non-Emergency  Repairs 

Read  Pressure  Gauge 

Report  Abnormal 

Report  Normal 

Check  Unloader 

Check/Fix  Other  Cases 

Check  For  Leaks 

Adjust  Unloader 

Verify  Normal 


Transitions:  Definitions 


r13 

14 

15 

16 

17 

18 

19 

20 


Observe  Fire 

EOW  Acknowledges,  Informs  Initiation  of  GQ 

Fire  Under  Control 

Fire  Not  Under  Control 

EOW  Checks  Personnel 

GQ 

Observe  Leak 
Post-Fork 
Pre-Fork 
EOCC 

Normal  Operation 

Order  to  Check  Pressure  Drop  Received  from  EOW 
EOW  Orders  Pressure  Drop  Check 

Pressure  Gage  Read 
Normal 

Investigation  Order  Received  from  EOW 

Normal 

Abnormal 

Leak  Found 

No  Leak  Found 

Receive  Feedback  from  EOW 
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Completion  Event 
Completion  Event 
Completion  Event 
Completion  Event 
Completion  Event 
Normal  Operation  Verified 


3. 


PERFORMANCE  AND  WORKLOAD  ANALYSIS  VIA  MODIFIED  PETRI  NETS  (MPN) 


3.1  MPN-Based  Task  Performance  Elicitation 


Given  a  prescriptive  model  of  actual  task  performance  (i.e.,  a  model 
constructed  with  the  help  of  available  procedural  documentation  in 
conjunction  with  elicitation  from  domain  experts  or  “good"  performers),  it 
is  possible  to  generate  a  sequence  of  questions  that  are  relevant  to 
extracting  "unobservable"  task  performance  variables.  Specifically,  within 
an  MPN  framework  the  types  of  questions  that  can  be  posed  to  elicit  the 
necessary  performance-related  information  include: 

(1)  For  the  problem  under  consideration  what  external  events 
require  an  action  response? 

(a)  How  many  such  events  are  there? 

(b)  Can  any  of  these  occur  simultaneously? 

(c)  How  do  you  respond  to  each  independently,  jointly? 

(2)  For  each  antecedent  event,  how  many  activities  do  you  perform 
in  parallel? 

(a)  Can  any  of  these  activities  be  done  sequential ly?  If  so, 
what  are  the  consequences  on  overall  task  performance? 

(3)  If  you  are  engaged  in  activity  A1  associated  with  handling 
event  E^,  and  event  E2  occurs  which  will  you  choose  from  the 
following? 


(a)  Suspend  A^  respond  to  E2  and  then  resume  Aj. 

(b)  Complete  Aj  and  then  respond  to  E2. 

(c)  Abandon  A^  respond  to  E2,  continue. 

(d)  Ignore  E2  altogether. 

(4)  What  is  the  typical  time  duration  associated  with  activity  A^? 

(5)  What  are  the  earliest  and  latest  times  for  taking  action 
following  action-necessitating  event  E,? 

J 

(a)  No  sooner  than  tm<n  after  Ej  occurs. 

(b)  No  later  than  tmax  after  Ej  occurs. 

(6)  If  there  are  problems  associated  with  performing  activity  Ak> 
then  what  are  the  subtasks  and  events  associated  with  Ak? 

3.2  MPN-Based  Workload  Measures 


To  estimate/predict  upperbound  of  workload  within  a  modified  Petri  net 
(MPN )  structure,  certain  definitions  are  necessary.  The  first  is  the 
notion  of  a  subnet  of  a  Petri  net.  For  a  part  of  a  PN  to  qualify  as  a 
complete  subnet  of  a  PN,  it  must  be  a  connected  subnet  of  a  Petri  net. 
With  this  definition  it  is  clear  that  a  complete  subnet  is  a  Petri  net  and 
any  Petri  net  is  a  complete  subnet  of  itself.  Since  every  complete  subnet 
is  a  PN,  it  can  execute  like  a  PN.  The  execution  of  a  subnet  produces  a 
marking  for  each  time  t  and  a  history  of  "fired"  transitions  along 
with  their  firing  times  t^,  (S^,  t^ )t  where  the  transitions  are  ordered  in 

accord  with  their  firing  sequence  up  to  time  t.  Consider  the  time  t  and 
let  the  markings  M^  have  n(t)  tokens  at  places  Pj  with  activity-related 
loads  wif  i=i,2,...  .  Also,  assume  that  event-related  loads  decay 
exponentially  over  time.  Then,  let  the  cardinality  of  the  set  (S^ ,  )  t 

be  m(t).  Let  the  event  load  for  be  v^ .  Then  the  instantaneous  workload 
(t),  can  be  defined  as  follows. 
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(1) 


where  At.  =  (t-t^),  and  x-j  is  a  rate  of  decay  parameter  for  the  ith 
transition.  The  quantity  z(t)  can  be  equated  to  the  instantaneous  stress 
associated  with  the  task  under  consideration. 


The  cumulative  workload  up  to  time  t  can  then  be  defined  as 


where  t  has  been  replaced  by  the  dummy  variable  u.  The  quantity  L(t)  can 
be  loosely  equated  to  task-induced  "fatigue",  that  is,  "fatigue"  associated 
with  the  task  under  consideration. 


Activity  Load.  The  load  imposed  by  an  activity  is  a  function  of  the  type 
of  activity  (i.e.,  static  or  dynamic).  The  types  of  activities  that  the 
operator  engages  in  can  be  conveniently  classified  into  skill-based, 
rule-based  and  knowledge-based  (Rasmussen,  1981).  Ski  11 -based  activities 
are  primarily  psycho-motor  or  manual  in  nature  (e.g.,  tracking, 
manipulating).  Rule-based  activities  are  predominantly  procedural  or 
pattern-matching.  Knowledge-based  activities  are  characterized  by  a 
predominant  cognitive  or  problem-solving  component.  A  discussion  of  each 
of  the  above  is  given  in  Appendix  C.  The  average  load  associated  with 
these  activities  is  shown  in  Table  3. 
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TABLE  3 

AVERAGE  ACTIVITY  LOAD  VERSUS  ACTIVITY  TYPE 


Places  (Associated  with  activities) 


Activity  Type 

Associated  Load 

Passive 

.1 

Active 

.  Skill -Based 

.3 

.  Rule-Based 

.4 

.  Knowledge-Based 

.7 

TABLE  4 

TRANSITION/EVENT  LOAD  VERSUS  EVENT  TYPE  AND  DECAY  TIME 


Transitions  (Combinations  of  internal  completion  and/or  external  events) 


Event  Type 

Decay 

Time 

Constant 

Associated  Load 

.  Internal  Completion 

1  sec 

.1 

.  External 

-  expected 

2  sec 

.2 

-  unexpected 
(containable) 

4  sec 

.4 

-  unexpected 
(catastrophic 

10  sec 

1.0 

.  Mixed 

(add  component 
weights) 

sum 

sum 

r 


B 


mi 


r 


I 

fl 


Transition  Load.  The  load  imposed  by  the  occurrence  of  one  or  more  events 
at  a  given  transition  is  largely  a  function  of  whether  the  event  is 
internal  or  external  to  the  task.  Figure  4  provides  a  convenient 
classification  of  events  for  our  purposes.  Table  4  provides  a  breakdown  of 
the  various  event(s)  that  can  occur  at  a  transition,  their  decay  times,  and 
their  associated  loads. 

Path-Related  Workload.  Within  the  Petri  net  framework  it  is  possible  to 
compute  several  workload  measures  (see  Figure  b).  First,  multiple 
path-related  workload  measures  can  be  computed  for  each  admissible  path. 
Second,  both  instantaneous  and  cumulative  measures  for  each  path  can  be 
computed.  In  practice,  paths  are  typically  designated  by  the 
analyst/designer.  The  PN  of  Figure  6  will  be  used  as  a  vehicle  to 
illustrate  the  notion  of  a  path. 

In  this  example,  for  instance,  the  following  two  major  paths  can  be 
defined: 


Path  1:  Pj 
Path  1:  Pj 


T 

T 


p7-t 


6 

7 

8 


From  the  above,  it  can  be  seen  that  a  path  is  a  complete  subnet  of  a  PN;  it 
can  have  both  forks  (and  joins).  The  underlying  idea  behind  the  notion  of 
a  path  is  to  identify  the  worst  case  workload  associated  with  a  task  and 
the  designated  paths  to  make  meaningful  assessments  about  task  reallocation 
if  overall  workload  is  excessive  but  reallocation  is  feasible. 


INTERNAL 

(I) 


Thus,  we  can  say  that  the  workload  associated  with  the  given  complete 
subnets  of  Figure  5  is  either  workload  associated  with  path  1  (WL1)  or  path 
2  (WL2)  depending  on  whether  transition  T1  or  T2  fires.  Maximum 
instantaneous  workload  associated  with  path  2  (WL2)  is  the  maximum  of 
workload  associated  with  path  21  and  path  22.  Maximum  overall 
instantaneous  task  workload  (ML)  can  then  be  defined  as  the  maximum  of  path 
1  instantaneous  workload  and  path  2  instantaneous  workload. 


The  lube  oil  problem  has  been  thus  far  used  as  a  vehicle  for  demonstrating 
the  representation  power  of  modified  Petri  net  models.  In  subsequent 
paragraphs,  a  key  segment  of  this  problem  will  be  abstracted  (see  Figure  7) 
and  used  to  illustrate  the  various  workload  measures  associated  with  the 
total  subnets  and  selected  paths  within  it.  The  illustrative  problem  is 
geared  to  the  EOOW's  decisionmaking  and  action  sequence.  It  starts  with 
the  receipt  of  a  lube  oil  leak  report  from  the  engine  room  and  ends  with 
the  restoration  of  normal  operation.  Specifically  within  this  problem 
representation,  the  securing  of  the  MRG  according  to  EOCC  is  expanded  in 
greater  detail  (Figure  8)  to  demonstrate  the  hierarchical  modelling  aspect 
of  the  approach.  Subsequently,  workload  measures  (instantaneous, 
cumulative,  and  average  cumulative)  are  computed  for  the  total  subnet  and 
the  designated  two  paths  in  the  net. 


TRANSITIONS 

Transition 

# 

Action 

Arcs 

From 

Arcs 

To 

Text 

T12 

YES 

pll 

p12 

PACC  operator  report  to  EOOW,  "No  lubeoil 

service  system  secured.  No _  GTMTtopped. 

It  is  at  CCS.  No  _  shaft  stopped  with  shaft 

brake  on. 

T13 

YES 

P12 

P13 

EPCC  operator  report  to  EOOW,  "No  GTG  is 

stopped.  No  _  GTG  is  online  and  in 

parallel  with  No _  GTG." 

T14 

YES 

P13 

P14 

Engineering  space  report  manned. 

T15 

YES 

P14 

P15 

No  engine  room  report  to  EOOW,  "Main 

reduction  gear  lube  oil  service  system  leak 
is  isolated." 

T16 

YES 

P15 

P16 

PACC  operator  report  to  EOOW,  "Bleed  air 
secure  from  No  GTM  and  isolated  from  No  3 

GTG." 

T17 

YES 

P16 

P17 

Unaffected  engine  room  report  to  EOOW, 

"Bleed  air  secured  from  No  _  GTG." 

T18 

YES 

P17 

P18 

No  engine  room  report  to  EOOW,  "Lube  oil 

flusWed  into  bilges;  covering  with  AFFF." 

T19 

YES 

P18 

P19 

000  grants  permission. 

T20 

YES 

P19 

P20 

No  _  engine  room  report  to  EOOW,  "Fire 

hazards  removed." 

T21 

YES 

P20 

P21 

No  engine  room  report  to  EOOW  cause  of 

the  casualty  and  estimated  time  to  repair. 

CM 

CM 

1— 

NO 

ph 

CM 

CM 

O. 

Casualty  cannot  be  restored  in  a  reasonable 
amount  of  time. 

T23 

YES 

P22 

P23 

OOD  grants  permission  to  stop  the  ship. 

H 

ro 

YES 

P23 

P24 

When  the  SHIP  SPEED  indicator  is  at  "0" 
knots,  PACC  operator  report  to  EOOW,  "ITC 
lever  is  at  'stop'  maintaining  zero  thrust 
on  No  _  shaft." 

41 


TRANSITIONS 


Transition 

§ 

Action 

Arcs 

From 

Arcs 

To 

Text 

T25 

YES 

P24 

P25 

PACC  operator  report  to  EQOW,  "No  shaft 

brake  is  released." 

T26 

NO 

P21 

P26 

Casualty  can  be  restored  in  a  reasonable 
amount  of  time. 

T27 

YES 

P26 

p27 

PACC  operator  report  to  EQOW,  "Throttle 
control  in  'AUTO'." 

T28 

YES 

P27 

P28 

000  orders  EOOW  to  transfer  ITC  control  to 
the  pilothouse. 

T29 

YES 

p28 

P29 

PACC  operator  transfers  ITC  control  to  the 
pilothouse. 

T30 

NO 

P29 

P30 

Affected  engine  was  operating  above  7500  RPM 
gas  generator  speed  for  all  or  part  of  the 
five  minutes  preceding  shutdown. 

T31 

NO 

P29 

P31 

Affected  engine  was  operating  at  or  below 
7500  RPM  gas  generator  speed  for  five 
minutes  or  more  preceding  the  shutdown 
(emergency  stopped). 

T32 

NO 

P25 

P32 

Shutdown  complete. 

T33 

NO 

P31 

P32 

Shutdown  complete. 

T34 

NO 

P30 

p 

j2 

Shutdown  complete. 

PLACES 

Place 

# 

Action 

Arcs 

From 

Arcs 

From 

Text 

P11 

YES 

t7 

T12 

EOOW  order  engineering  spaces  manned. 

P12 

YES 

T12 

T13 

EOOW  report  to  OOO,  “Major  lube  oil  leak  in 

No  engine  room.  No  GTM  is  stopped, 

ITCH’S  at  CCS.  No _  sFaft  Is  stopped  with 

shaft  brake  on.  Maximum  speed  is  _  knots." 

P13 

YES 

T13 

T14 

Monitor. 

P14 

YES 

T14 

T15 

Monitor. 

P15 

YES 

T15 

T16 

Monitor. 

P16 

YES 

Tie 

T17 

Monitor. 

P17 

YES 

T17 

T18 

Monitor. 

P18 

YES 

T18 

T19 

EOOW  report  to  00D,  "Major  lube  oil  leak  in 

No  engine  room  Is  isolated.  Lube  oil  in 

No  engine  room  is  flushed  into  bilges  and 

covered  with  AFFF."  EOOW  request  permission 
from  000  to  remove  fire  hazards  (in 
accordance  with  current  environmental 
protection  requirements). 

P19 

YES 

T19 

T20 

EOOW  orders  No  engine  room  to  remove  fire 

hazard  (In  acconlance  with  current 
environmental  protection  requirements). 

P20 

YES 

T20 

T21 

EOOW  report  to  000,  "Fire  hazards  removed 

from  No  _  engine  room."  EOOW  order  No  _ 

engine  room  to  investigate  for  the  cause  of 
the  casualty  using  approved  maintenance 
procedures  and  technical 

P21 

YES 

T21 

122 

'26 

EOOW  report  to  00D  the  cause  of  the  casualty 
and  estimated  time  to  repair. 

P22 

YES 

T22 

T23 

EOOW  request  permission  from  000  to  stop  the 
ship  to  lock  No  _  shaft. 

PLACES 


Place 

I 

Action 

Arcs 

From 

Arcs 

From 

Text 

P23 

YES 

T23 

T24 

EOOW  order  PACC  operator  to  place  the 
unaffected  shaft  ITC  lever  at  "STOP"  and 
maintain  zero  thrust. 

P24 

YES 

T24 

T25 

EOOW  order  PACC  operator  to  release  the  - 
shaft  brake  on  the  affected  shaft. 

P25 

YES 

T25 

T32 

EOOW  lock  No  _  shaft. 

P26 

YES 

T26 

T27 

EOOW  order  PACC  operator  to  shift  throttle 
control  to  ''AUTO." 

P27 

YES 

r27 

T28 

EOOW  report  to  OOD,  "Throttle  control  in 
'AUTO'.  CCS  is  standing  by  to  transfer  ITC 
control  to  the  pilothouse." 

00 

C\J 

a. 

YES 

T28 

t29 

EOOW  order  PACC  operator  to  transfer  ITC 
control  to  the  pilothouse. 

P29 

YES 

T29 

T31 

'30 

EOOW  report  to  OOD,  "ITC  control  transferred 
to  the  pilothouse.” 

P30 

YES 

T30 

T32 

EOWW  order  PACC  operator  to  cool  down 
affected  GTM. 

P31 

NO 

T31 

T32 

No  orders. 

P32  YES  T 32  Tg  Repairs  proceeding. 
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Net  Execution 


The  net  executes  by  moving  tokens  through  a  sequence  of  places 
(activities).  The  execution  of  the  net  is  non-unique.  It  is  a  function  of 
which  transitions  fire.  With  respect  to  the  illustrative  example  there  are 
two  possible  paths,  p1  and  p2  (Figure  7). 


Performance  Measures 


Several  performance  measures  associated  with  the  lube  oil  leak  recovery 
task  (Figure  7)  can  be  used  to  evaluate  both  fractional  and  global  task 
performance.  These  include: 

(1)  Event-Related  Measures 


-  Failure  to  react  to  lube  oil  leak  in  time  interval  t  since 
receipt  of  report. 

-  Failure  to  evaluate  type  of  leak  before  proceeding  with 
corrective  action. 

-  Failure  to  check  MRli  pressure  after  securing  old  pump. 

-  Failure  to  verify  normal  operation  at  the  end  of  recovery 
sequence. 
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(2)  Time-Based  Measures  (associated  with  activities  that  have 
internal  completion  events). 

-  Time  to  react  to  lube  oil  leak  report. 

-  Time  to  ascertain  location  and  magnitude  of  leak. 

-  Time  to  start  new  pump. 

-  Time  to  secure  old  pump. 

-  Time  to  check  MRG  pressure  after  securing  old  pump. 

-  Time  to  perform  non-emergency  repairs. 

-  Time  to  secure  MRG  according  to  EOCC. 

-  Time  to  evaluate/restore  normal  operation. 

(3)  Incorrect  Responses  (extraneous  steps,  i.e.,  response  to 
spurious  events/execution  of  redundant  actions  observed  in 
actual /simulated  task  performance  or  elicited  from  the 
operator/maintainer  in  "think-aloud"  session  or  during 
post-exercise  interview). 

(4)  Procedure-Related  Measures.  These  measures  are  associated 
with  failure  to  follow  required  steps  indicated  in  EOSS/EOCC, 
for  example,  steps  associated  with  expansion  of  Pg  in  Figure 
8.  Specific  examples  include: 

-  Failure  to  issue  specific  order  to  Officer  on  the  Deck 
(00D). 

-  Failure  to  request  specific  permission  from  00D. 

-  Failure  to  make  specific  report  following  initial  incident. 
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Workload  Estimation 


The  instantaneous  workload  associated  with  each  of  these  paths  is  generally 
different.  A  sample  execution  of  the  net  of  the  illustrative  example  is 
given  in  the  printout  (Appendix  D).  Each  transition  that  "fires"  is  shown 
along  with  its  firing  time  and  the  resultant  token  positions.  Figures  9 
and  10  provide  sample  profiles  of  the  instantaneous  and  cumulative  workload 
profiles  associated  with  Path  Px  0f  the  illustration  problem. 

3.4  MPN-Based  Task  Concurrency  and  Workload  Analysis 

Thus  far,  the  MPN  modelling  approach  has  been  presented  as  a  means  for 
characterizing  maximum  workload  levels.  In  this  section,  it  will  be  shown 
how  these  models  can  be  used  to  expose  possible  task  concurrencies  when 
performing  missions.  It  will  also  be  shown  that  at  the  lowest  or  next  to 
the  lowest  level  of  abstraction  in  the  MPN,  each  activity  and  combination 
of  activities  can  be  assigned  reliable  workload  ratings  by  experts  (Madni 
and  Lyman,  1983).  A  discussion  of  possible  sources  of  workload  is  provided 
in  Appendix  F.  Since  an  MPN  model  may  be  hierarchically  expanded  in 
increasing  levels  of  detail,  it  is  possible  to  expand  the  net  to  the 
man-machine  interaction  (MMI)  level  when  representing  a  shipboard 
propulsion  systems  maintenance  task.  Examples  of  the  lower  level  of  such 
an  expansion  for  the  lube  oil  problem  handling  are  given  in  Figure  2  and  3. 

Workload  values  can  be  subjectively  elicited  from  experts  either  at  this 
level  or  at  the  next  highest  level.  Engineering  officers  or  journeymen  who 
have  performed  such  tasks  feel  comfortable  assigning  workload  values  to  the 
individual  activities  or  combination  of  activities  described  at  these 
levels.  In  addition,  the  minimum  and  maximum  time  required  to  perform  each 
activity  are  elicited  from  the  experts.  These  execution  times  are 
necessary  to  compute  the  possible  combination  of  activities  that  need  to  be 
performed  concurrently.  This  is  illustrated  in  the  abstract  net  and  table 
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FIGURE  9. 

INSTANTANEOUS  WORKLOAD  PROFILE 


FIGURE  10. 

CUMULATIVE  WORKLOAD  PROFILE 


of  Figure  11.  In  order  to  illustrate  this  principle,  we  take  two  possible 
scenarios  for  this  net  and  look  at  the  particular  conjunction  of  activities 
required  in  each  case.  Suppose  that  the  following  times  are  taken  by 
activities  P2-P6: 


Activity 

Average  Execution  Time  (sec) 

10 

P3 

10 

P4 

1 

P5 

10 

P6 

10 

Then,  the  only  conjunctions  that  would  occur  would  be  PI,  P2  A  P5,  P3 A  P6 
and  P4,  where  '  A'  represents  conjunction.  On  the  other  hand,  let  us  say 
that  the  execution  times  were  as  follows: 


Activity 


Average  Execution  Time  (sec 


The  process  of  generating  conjunctions  involves  "executing"  the  MPN  (either 
manually  or  via  computer  simulation)  using  the  execution  times  related  to 
the  activities.  The  complete  MPN,  task  descriptions,  and  primitive 
execution  times  can  be  elicited  from  experts. 

Any  connected  subsection  of  an  MPN  is  a  subnet  of  that  MPN.  Some  sample 
subnets  of  an  MPN  are  given  in  Figure  6.  With  respect  to  this  figure,  it 
is  easy  to  see  how  we  could  consider  the  subnet  obtained  by  deleting  Path 

2j.  If  we  found  that  the  workloads  over  the  new  subnet  were  sufficiently 
reduced  from  those  of  the  original  MPN,  the  subnet  Path  2,  would  be  a  good 
candidate  for  performance  enhancement  or  automation. 

For  purposes  of  workload  analysis,  subnets  that  are  complements  of  other 
subnets  (which  have  been  tentatively  selected  for  automation),  can  be 
isolated.  To  investigate  the  workload  reduction  attributed  to  each 
candidate  for  performance  enhancement  (e.g.,  interface  redesign  or 
maintainability  aids)  it  is  necessary  in  the  proposed  analysis  scheme  to 
consider  candidate  subnets  for  enhancement  and  look  at  the  complement  nets 
to  these  subnets.  By  obtaining  workload  values  for  the  entire  net  and  all 
the  complement  subnets,  one  can  decide  which  subnets  should  be  considered 
for  possible  enhancement. 

As  Figure  11  indicates,  an  MPN  without  execution  times  is  often  inadequate 
to  determine  all  the  conjunctions  of  tasks  that  could  occur  simultaneously. 
Using  Figure  11  and  the  minimum  and  maximum  execution  times  for  the  places, 
we  can  obtain  the  following  lists  of  possible  task  conjunctions  and 
non-conjunctions: 
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1. 

PI, 

P2 

and 

P5, 

P3 

and 

P6, 

P4 

2. 

PI, 

P2 

and 

P5, 

P3 

and 

P5, 

P4 

and 

P6, 

P6 

3. 

PI, 

P2 

and 

P5, 

P3 

and 

P5, 

P4 

and 

Pb, 

P6 

4. 

PI, 

P2 

and 

P5, 

P3 

and 

P5, 

P4 

and 

P5, 

P5, 

P6 

5. 

PI, 

P2 

and 

P5, 

P2 

and 

P6, 

P3 

and 

P6, 

P4 

6. 

PI, 

P2 

and 

P5, 

P2 

and 

P6, 

P3 

and 

P6, 

P3, 

P4 

7. 

PI, 

P2 

and 

P5, 

P2 

and 

P6, 

P3 

and 

P6, 

P4 

ana  P6 

To  obtain  an  exhaustive  list  of  all  concurrencies  and  non-concurrencies,  it 
is  necessary  to  run  a  large  number  of  Monte  Carlo  simulations  of  the  MPN 
with  execution  times  for  places  varying  between  the  minimum  and  maximum 
execution  times.  In  general,  running  Monte  Carlo  simulations  are 
necessary,  unless  the  net  is  simple  enough  so  that  all  task  concurrencies 
and  non-concurrencies  can  be  enumerated  by  inspection  or  alternatively 
listed  by  an  expert  with  the  ability /experience  to  recall  all 
contingencies. 

The  process  of  getting  all  concurrencies  and  non-concurrencies  must  be 
repeated  for  every  complement  subnet  before  selecting  a  candidate  subnet 
for  enhancement.  Once  all  of  the  concurrencies  and  non-concurrencies  for 
each  complement  subnet  and  candidate  subnet  as  well  as  the  full  net  have 
been  identified,  workload  values  can  be  elicited  from  an  expert  for  each 
task  combination  in  the  list.  This  provides  a  report  of  the  instantaneous 
workloads  possible  with  and  without  various  possible  enhanced  subnets. 

One  can  then  use  these  subjective  workload  values  to  decide  on  which  subnet 
to  enhance.  The  value  of  workload  elicited  for  each  situation  should  be  on 
a  relative  scale  of  0  of  high  difficulty  should  be 
defined  by  the  expert  on  this  scale. 


Certain  subnets  will  have  complement  subnets  in  which  the  higher  values  of 
workload  are  considerably  less  than  for  the  full  net.  These  subnets  are 
potential  candidates  for  enhancement.  Particularly,  when  all  or  most  of 
the  workloads  fall  below  the  expert -defined  threshold  for  the  complement  of 
a  subnet,  one  can  feel  fairly  confident  that  if  the  subnet  is  enhanced  or 
automated,  the  remaining  tasks  will  be  "do-able"  by  the 
operator/mai ntai ner . 

3.5  Projected  Analysis  of  Navy  Maintenance  Data 

CASREP  and  3M  Reports  covering  the  Main  gas  Turbine  Propulsion  System  for 
the  DD963  class  of  ship  for  the  period  January  1980  through  December  1982 
have  been  received  from  the  Navy  Maintenance  Support  Center  and  the  Navy 
Ship  Parts  Control  Center,  Mechanicsburg,  PA.  Analysis  of  these  data  is 
currently  in  progress  and  the  results  will  be  reported  in  a  subsequent 
technical  report.  These  data  will  be  analyzed  to  determine  their  potential 
as  a  data  source  for  confirming  the  data  elicited  from  subject  matter 
experts  and  for  validating  the  MPN  model. 
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PETRICONTRUL  SOFTWARE  PACKAGE 


C 


■ 


l* 


The  PETRICONTROL  package  accepts  a  user-defined  task  within  an  MPN 
representation,  executes  it,  and  prints  out  net  execution  and  workload 
information.  The  user  defines  the  net  at  the  logical  level  by  creating  a 
file  containing  the  requisite  information  in  character  format.  The 
required  information  is  specified  below  and  must  be  provided  in  the 
indicated  order  and  format  with  one  or  more  blanks  or  carriage  returns 
between  adjacent  values  (note—  multiple  value  fields  and  text  are  followed 
by  a  semicolon): 

@,  Label,  type  of  node,  subtype,  associated  Boolean  expression, 
hierarchical  level,  basic  workload  weight,  workload  decay  half-life, 
forward  arcs,  backward  pointers,  hierarchical  down-pointer,  hierarchical 
up-pointer,  inhibition  arcs  (other  end),  text.  The  last  record  is  followed 

by  (s*@. 

Label .  The  label  consists  of  up  to  9  characters  for  the  current  place 
or  transition. 

Type  of  Node.  The  type  is  specified  as  P  for  place  or  T  for 
transition. 

Subtype.  Possible  subtypes  with  associated  codes  are: 

-Place 

-1  Monitor  until  event 

n  >p  0  Activity  requiring  n  seconds 


S5 


‘  ■  -IV. ■>- 


■  1 


-Transition 


0  Internal  completion 

1  External  event  or  condition 

2  Mixed  (internal  completion  and/or  external  event  or 

condition 

Associated  Boolean  Expression.  This  must  be  U  for  a  place  but  gives 
the  firing  conditions  for  a  transitici  (see  Figure  12  below). 


IC 

Internal  completion 

En 

External  event  n  n  _>  U 

Cn 

External  condition  n  n  _>  u 

ICAEn, 

ICVEn 

Mixed  expression  i 

ICACn, 

ICVCn 

Mixed  expression 

Figure  12.  Firing  Conditions  for  Transitions 

Hierarchical  Level.  This  is  the  level  in  the  hierarchy  of  the  current 
node  in  the  Petri  Net.  The  levels  start  at  1  and  increase  as  you  go 
lower  (i.e.,  down)  in  the  hierarchy. 


Basic  Workload  Weight.  The  workload  weight  for  a  place  or  transition 
is  a  floating-point  number.  The  weights  are  provided  in  Table  5. 


-Places 

Passive 

.1 

Active 

Skill  based 

.3 

Rule  based 

.4 

Knowledge  based 

.7 

-Transitions 

Internal  completion 

.1 

External 

Expected 

.2 

Unexpected  (containable) 

.5 

Unexpected  (catastrophic) 

1.0 

Mixed 

Add  respective  components 

such  as 

Internal  Completion  +  External  Expected 

*  .1  +  .2  *  .3 

Table  5.  Workload  Weights  for  Places  and  Transitions 


Workload  Decay  Halflife.  The  workload  contributions  of  transitions 
follow  an  exponential  decay  with  time.  The  numbers  of  seconds  for  the 
halflife  of  these  decay  processes  are  specified  in  Table  6  below: 


Transition  Type 

Half life  (in  seconds) 

Internal  completion 

External 

1 

Expected 

2 

Unexpected  (containable)  4 

Unexpected  (catastrophic)  10 

This  value  is  set  to  0 

for  places. 

Table  6.  Halflife  for  Exponentially  Decaying  Transition-Related  Loads 


57 


Forward  Arcs.  The  nodes  pointed  at  by  the  forward  arcs  leaving  the 
current  node  are  specified  by  their  labels.  Up  to  10  arcs  are  allowed. 

Backward  Pointers.  The  nodes  with  arcs  pointing  to  the  current  node 
are  specified  by  their  labels.  Up  to  10  arcs  are  allowed. 

Hierarchical  Down-Pointer.  If  the  current  node  has  an  hierarchical 
expansion,  the  label  of  the  first  node  of  that  expansion  is  provided. 

Hierarchical  Up-Pointer.  If  the  current  node  is  the  final  node  in  an 
hierarchical  expansion  of  a  higher  level  node,  then  the  label  of  that 
higher  level  node  is  given  here. 

Inhibition  Arcs.  If  the  current  node  has  any  inhibition  arcs  coming 
into  it  or  leaving  it,  the  labels  of  the  other  ends  of  those  arcs  is 
given  here.  Up  to  10  labels  may  be  used. 

Text.  Up  to  359  characters  of  text  describing  the  current  node  may  be 
specified  here. 

An  example  logical  data  file  follows  (see  Figure  13).  To  illustrate 
more  clearly  how  to  enter  such  a  file,  find  T2  six  lines  down  in  the 
file  and  interpret  it  as  follows: 

Label  =  T2,  Type  =  T,  Sub-type  =  2,  Boolean  Expression  =  IC&C1, 
Level  =  1,  Weight  =  0.3,  Halflife  =  3,  Forward  nodes  are  P3  and  P5, 
Backpointer  is  P2,  there  are  no  hierarchical  or  inhibition  pointers, 
and  the  text  is  "Prefork  leak." 
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Juri  23  15:04  1383  PETRIdata  Page  1 


9  PI  P  -1  0  1  0.  1  0  Tl; 

T9; 

0 

0 

0; 

Monitor  MRG  oressure  gauge. ; 
rg  Tl  T  1  El  1  1.0  10  P2; 

Pi; 

0 

0 

0; 

Enaine  room  reoorts  major  lube  oil  leak  in 

MRG  lube  oil 

system. ; 

i?  P2  P  5  0  1  0. 7  0  T2  T7; 

Tl; 

0 

0 

0; 

Evaluate  magnitude  and  location  of  leak.; 

9  T2  T  2  IC&C1  1  0.3  3  P3  P5; 

P2; 

0 

0 

0; 

Prefork  leak. ; 

9  P3  P  5  0  1  0. 3  0  T3; 

T2; 

0 

0 

0; 

Start  new  pump. ; 

0  T3  T  0  IC  1  0. 1  1  P4; 

P3; 

0 

0 

0; 

New  pumo  started. ; 

9  P4  P  5  0  1  0. 3  0  T4; 

T3; 

0 

0 

0; 

Secure  old  oump. ; 

9  P5  P  SO  1  0. 3  0  T4; 

T2; 

0 

0 

0; 

Inform  engine  room. ; 

9  T4  T  0  IC  1  0.  1  1  P6; 

P4  P5; 

0 

0 

0; 

□Id  oump  secured  and  engine  room  informed. 
9  P6  P  SO  1  0. 3  0  T5; 

'14  = 

0 

0 

0; 

Check  MRG  pressure.  ; 

9  T5  T  O  IC  1  0. 1  1  P7; 

P6; 

0 

0 

0; 

Verify  normal. ; 

C-  P7  P  15  O  1  0.3  0  T6; 

T5; 

0 

0 

0; 

Perform  r  in-emergency  repairs.  ; 

9  T6  T  0  IC  1  0. 1  1  PS; 

P7; 

0 

0 

0; 

Reoair  complete. ; 

9  T7  T  2  IC&C2  1  0.3  3  P8; 

P2; 

0 

0 

0; 

Post  fork  leak.  ; 

@  P8  P  -1  O  1  0.0  0  T8; 

T7; 

Pll 

0 

0; 

Inform  engine  room  of  EOCC. ; 

9  T8  T  O  IC  1  -0. 1  1  P9; 

P8; 

0 

0 

0; 

Engine  room  informed  and  repairs  complete. 
9  PS  P  20  1  0.7  0  T9; 

a 

’T6  TS; 

0 

0 

0; 

Evaluate/restore  normal  operation. ; 

C*  T9  T  0  IC  1  0.1  1  PI; 

P9; 

0 

0 

0; 

Normal  ooeration  restored.  ; 

@  Pll  ?  20  2  0.3  0  T12; 

T7 ; 

0 

0 

0; 

EOW  orders  engineering  spaces  manned. ; 

9  T12  T  2  IC&E2  2  0. 3  3  P12; 

Pll; 

0 

0 

0; 

PACC  operator  reports  to  EOW,  "No.  i  lube  oil  service  system  secured. 
No.  i  GTM  stooped.  It  is  at  CCS.  No.  i  shaft  stoooed  with  shaft  brake 
on.  " ; 

9  P12  P  10  0  2  0.4  0  T13;  TIE;  000; 

EOW  reoorts  to  00D,  "Major  lube  oil  leak  in  no.  i  engineroom.  No.  i 
GTM  is  stooped.  ITC  is  at  CCS.  No.  i  shaft  is  stoooed  with  shaft 
brake  on.  Maximum  speed  available  is  i  knots."; 


9  713  7  2  IC&E3 

2  0.  3  3  P13; 

P12; 

0 

0 

0; 

EPCC  ooerator  reoorts  to  EOW,  "No.  i  GTG 

is  stoooed. 

No.  i 

GTG 

is 

online  and  in  oarallel  with  no.  i  GTG. " ; 
i?  P13  P  -1  0  2  0.  1  0  T14; 

713; 

0 

0 

0; 

Monitor.  ; 

9  T 14  7  1  E4 

2  0.2  2  P14; 

P13; 

0 

0 

0; 

Engineering  SQaces 
@  P 1 4  P  -10 

reDort  mannea. ; 

2  0. 1  0  715; 

T14; 

0 

0 

0: 

Monitor.  ; 

9  <  15  7  1  c5 

2  0.2  2  P15; 

P14; 

0 

0 

0: 

FIGURE  13. 

LOGICAL  PETRI  NET  FOR  ILLUSTRATIVE  PROBLEM 


59 


Jun  £3  15:214  1983  PETRIdata  Page  £ 


No.  i  engineroom  reoorts  to 

EOW,  "Main 

reduct  ion 

gear 

lube  oil  service 

system  leak  is  isolated."; 
i?  P15  P  -1  0  £  0.  1 

0 

T16; 

T15; 

0  0 

0; 

Monitor.  : 

C-  T16  T  1  ES  2  0.2 

2 

P16; 

P15; 

0  0 

0; 

PACC  ooerator  reoorts  to  EOW, 

“Bleed  air  secured 

from 

no.  i  GTM 

and 

isolated  from  no.  3  GTG. " ; 

9  P16  P  -1  0  £  0. 1 

0 

T17; 

T16; 

0  0 

0; 

Monitor. ; 

9  T 17  T  1  £7  2  0.2 

2 

P17; 

PIG; 

0  0 

0; 

Unaffected  engineroom  reoorts 

to  EOW,  *' 

Bleed  air 

secured  from  no.  i  GTG. 

9  P17  P  -1  0  2  0. 1 

0 

T18; 

.  T17; 

0  0 

0; 

Monitor. ; 

9  Tia  T  1  E8  2  0.2 

2 

PIS; 

P17; 

0  0 

0; 

No.  l  engineroom  reoorts  to 

EOW,  "Lube 

oil  flushed  into  bilges. 

covering 

with  AFFF. “ ; 

G>  P18  P  15  0  2  0.4 

0 

T19; 

T18; 

0  0 

0; 

EOW  reports  to  OOD,  "Major  lube  oil  leak  in  no.  i  engineroom  is  isolated. 
Lube  oil  in  no.  i  engineroom  is  flushed  into  bilges  and  covered  with  AFFF. " 
EOW  requests  oermission  from  OOD  to  remove  firs  hazards  (in  accordance  with 
current  environmental  orotection  reauirements) . " ; 


®  T19 

T  0 

IC  2  0.  1 

1  P 19; 

P18? 

0  0  0; 

COD  grants 

permission. ; 

9  PIS 

P  10 

0  2  0.4 

0  T20; 

T19; 

0  0  0; 

EOW  orders  no.  i  engineroom  to  remove  fire  hazards  (in  accordance  with 
environmental  protection  reauirements) . ; 

9  T20  T  0  IC  2  0.1  1  P20;  P19;  0  0  0; 

Xo.  i  engineroom  reporta  to  EOW,  "Fire  hazards  removed.  '* ; 

0  P20  P  10  0  2  0.4  0  T21 ;  T20;  0  0  0; 

EOW  reports  to  OOD,  "Fire  hazards  removed  from  no.  i  engineroom. "  EOW  orders 
no.  i  engineroom  to  investigate  for  the  cause  of  the  casualty  using  approved 
maintenance  procedures  and  technical  manuals. ; 

@  T21  T  £  IC&E9  2  0.3  3  P21;  P20;  000; 

No.  i  engineroom  reports  to  EOW  cause  of  the  casualty  and  estimated  time  to 


repair.  ; 

9  P21  P  10  0  2  0.4  0  T22  T26;  T21 ;  000; 


EOW  reports  to  OOD  the  cause  of  the  casualty  and  estimated  time  to  repair. 
C-  T22  T  £  IC&E10  £0.5  5  P£2;  P21 ;  0  0  0; 


Casualty  cannot  be  restored  in  a  reasonable  amount  of  time.; 

9  P£2  P  50  2  0.3  0  T23;  T£2;  000; 

EOW  reauests  permission  from  OOD  to  stop  the  ship  to  lock  no.  i  shaft. ; 
9  T23  T  0  IC  2  0.  1  1  P£3;  P££;  0  0  0; 

OOD  grants  permission  to  stop  the  ship. ; 

9  P£3  P  15  0  2  0.3  0  T24;  T23;  000; 


EOW  orders  PACC  operator  to  place  the  unaffected  shaft  ITC  lever  at  ’STOP* 
and  maintain  zero  thrust. ; 

1  T£4  T  0  IC  2  0.1  1  P24;  P23;  000; 

when  the  SHIP  SPEED  indicator  is  at  "0"  knots,  PACC  ooerator  reports  to  EOW, 

"ITC  lever  is  at  ’STOP’.  Maintainina  zero  thrust  on  no.  i  shaft."; 

9  P£4  P  50  £  0.3  0  T25 ;  '  T£4;  0  0  0; 

EOW  orders  PACC  ooerator  to  release  the  shaft  brake  on  the  affected  shaft. ; 


lit 

V  1  CwJ  1 

0  IC  £  0.  1 

X 

P25; 

P£4 ; 

0 

ft 

®; 

PACC  operator  reoorts  to  EOW 

9 

"No. 

i  snaft  brake 

is  released. 

'»  • 

• 

9  P£5  P 

3  0  £0.3 

0 

“32: 

i  k-U  * 

0 

0 

0; 

EOW  locks 
9  732  T 

no.  l  shaft. ; 

£  IC  2  0. 1 

• 

P32; 

D5*5  • 

0 

0 

0: 

FIGURE  13  (CONT'D) 
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Shutdown  complete.  ; 

©  T36  T  £  IC&E11  2  0.  3  3  P28;  P21;  0  0  0; 

Casualty  can  be  restored  in  a  reasonable  amount  of  time. ; 

©  P£6  P  50  £  0.3  0  T27 ;  T£6;  0  0  0; 

EOW  orders  PflCC  operator  to  shift  throttle  control  to  ’ AUTO’ . ; 

©  T£7  T  0  IC  £  0.  1  1  P27 ;  P26;  0  0  0; 

PflCC  operator  reports  to  EOW,  "Throttle  control  in  * AUTO’ . " ; 

©  P£7  P  10  0  £  0.3  0  T28;  T27;  000; 

EOW  reports  to  00D,  "Throttle  control  in  ’ AUTO’ .  CCS  is  standing  by  to 
transfer  ITC  control  to  the  pilothouse."; 

©  T£8  T  0  IC  2  0. 1  1  P28;  P27;  000; 

00D  orders  EOW  to  transfer  ITC  control  to  the  pilothouse. ; 

©  P28  P  10  0  2  0.2  0  T29;  T28;  000; 

EOW  orders  PACC  ooerator  to  transfer  ITC  control  to  the  Pilothouse. ; 

©  T£9  T  0  IC  £  0. 1  1  P29;  P28;  000; 

PflCC  ooerator  transfers  ITC  control  to  the  oi lot house. ; 

0  P29  P  50  2  0.3  0  T31  T30;  T29;  000; 

EOW  reoorts  to  00D,  "ITC  control  transferred  to  the  Di lot house. " ; 

©  T31  T  £  IC&C3  2  0.3  3  P31;  P29;  000; 

Affected  engine  was  ooerating  at  or  below  7500  RPM  gas  generator  speed  for 
five  minutes  or  more  preceding  the  shutdown  (emergency  stopped).; 


©  P31  P  10 

No  orders. ; 

2  0.3 

0  T33 ; 

T31 ; 

0 

0 

0; 

©  T33  T  1  IC 

Shutdown  complete. ; 

2  0.  1 

1  P32; 

P31 ; 

0 

0 

0; 

©  T30  T  2  1C&C4 

2  0.3 

3  P30; 

P29; 

0 

0 

0; 

Affected  engine  was  operating  above 
part  of  the  five  minutes  preceding 

7500  RPM  gas  generator  speed 
shutdown. ; 

for 

©  P20  P  3  0  2  0.3 

EOW  orders  PflCC  ooerator  to 

0  T34;  T30; 

cool  down  affected  GTM. ; 

0 

0 

0; 

9  T34  T  2  IC&E12 

Shutdown  complete. ; 

2  0.3 

3  P32; 

P30; 

0 

0 

0; 

©  P32  P  £5  0 
Repairs  proceeding. 

2  0.3 

5 

0  T35; 

T32  T33  T34 ; 

0 

0 

0; 

©  T35  T  0  IC 

Dummy  complete.  ; 

2  0.0 

0  P33; 

P32; 

0 

0 

0; 

©  P33  P  00 

2  0.0 

0  T8; 

T35; 

0 

pa 

0; 

Dummy  zero-wait  hold.  ; 
©@ 


FIGURE  13  (CONT'D) 
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Additional  Input 

At  this  stage,  there  is  no  world  model,  yet  events  and  conditions  must 
occur  in  some  way.  The  present  scenario  generator  looks  for  the  presence 
of  tokens  in  some  precursor  place  to  set  an  event  or  condition  to  true. 
The  data  structures  that  must  be  specified  are  'condlist',  'eventlist',  and 
'evcnmak'.  'Condlist'  and  'eventlist'  are  the  lists  for  all  defined 
conditions  and  events,  respectively,  with  their  associated  truth  values 
(initialized  to  ' F ‘  for  false).  'Evcnmak'  provides  an  association  between 
alternative  events  and  conditions  and  their  associated  precursor  places. 
These  structures  in  the  external  file  are  illustrated  in  Figure  14. 

Output 

If  the  user  specifies  one  run  at  a  time  when  a  Petri  Net  is  executed, 
PETRICONTROL  gives  the  transitions  as  they  fire  and  the  time  of  firing, 
each  successive  marking,  and  finally,  instantaneous  and  cumulative 
workload.  If  the  user  wants  just  the  average  workload  for  the  task,  100 
passes  (executions  of  the  net)  are  performed  and  the  final  cumulative 
average  workload  is  printed.  A  sample  printout  is  given  in  Appendix  C. 


b  2 
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/*  petriext.c 

6/6/83 — Denis  D.  Purcell 

PROCEDURE: 

External  globals  definition. 

PURPOSE: 

Defines  all  externals  needed  for  Petri  net 
implement at  ion. 


*/ 


/* 

Petri  net  structure. 

*/ 

struct 

-petrinet 
<  char 

label C10]  ; 

char 

type? 

short 

stype; 

*  short 

inprocess; 

char 

propC203 ; 

short 

tokens; 

short 

level ; 

short 

token level ; 

float 

weight; 

short 

halflife?  , 

short 

farcsC10] ; 

short 

bptrsCl03 ; 

short 

dptr; 

short 

uptr; 

short 

inhibsC103 ; 

char 

text  C3603 ; 

struct 

*  t 

petrinet 

maintainC1003 ; 

/* 

Structure  location  of 

Petri  net  nodes. 

*/ 

char 

labeltableC1003 C103 ; 

/* 

History 

of  markings  in 

net. 

*/ 

struct 

petri mark 
<  short 

index; 

short 

tokens ; 

char 

label C 10]  ; 

short 

\  m 

level ; 

struct 

*  f 

petr imark 

hi st mark  Cl 001 C203 ; 

/* 

History 

of  marking  times. 

*/ 

short 

histmt imeC1003 

• 

1 

/* 

Current 

history  index, 

last  print  index,  and  elapsed  time. 

*/ 

int 

histind; 

int 

lastpr int ; 

int 

elapsdt ime; 

/* 

History 

of  transitions 

fired  in  net. 

*/ 

struct 

petr itran 

— 

■C  short 

index ; 

char 

label C103 ; 

short 

\  • 

level ; 

struct 

*  » 

petritran 

h i st t ran C 1003  C203 ; 

FIGURE  14. 
MPN  INPUT 

STRUCTURE 
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History  of  transition  times  index, 
int  htransind; 

History  of  transition  times, 
short  htranst imeC1003 ; 

List  of  conditions  and  their  truth  values, 
struct  rwlist 

<  char  label C103; 

char  tvalue; 

>  condlist Cl 003  = 

Initialise  condlist. 

{"C1\0  ",  ’  F’ ,  "C2\0  'VF’,"C3\0 

"C4\0  ’  F’ , " \0  " >; 

List  of  events  and  their  truth  values, 
struct  rwlist  event  1 ist Cl 003  * 

Initialise  eventlist. 


E1\0 

",  ’ F* , "E2\0 

",  »F’ 

E3\0 

",  *F» ,  “E4\0 

“ ,  ’  F’ 

E3\0 

",  *F» ,  "E6\0 

",  ’  F' 

E7\0 

",’F»,  "E3\0 

",  ’  F’ 

E9\0 

4* ,  ’  F’  ,  "E10\0 

",  »F» 

E11N0 

",  ’ F’ , "E1£\0 

F’ 

\0 

Event  and  condition  creat ion-driving  structure, 
struct  crdrv 

■C  char  placeC103; 

char  happen C43 Cl£  3 ; 

>  evcnmakC.1003  » 

Initialise  evcnmak. 


P1\0 

\0 

",  "E1\0 

n 

1 

",  "\0 

II 

1 

"\0 

P1\0 

\0 

",  "C1\0 

ii 

1 

",  "C2\0 

II 

1 

"  \  0 

P 1  1  \0 
\0 

",  "E2\0 
•1 

1 

",  "\0 

II 

1 

”\0 

P1£\0 

\0 

", “E3\0 

II 

1 

",  "\0 

tl 

1 

"\0 

P13\0 

\0 

", "E4\0 

II 

1 

"\0 

ll 

1 

"\0 

P14\0 

\0 

", "E5\0 

ll 

1 

",  "\0 

II 

1 

"  \  0 

P15\0 

\0 

", "ES\0 

ll 

9 

",  "  \  0 

II 

9 

”\0 

P16\0 

\0 

", "E7\0 

II 

9 

",  "\0 

II 

9 

"  \0 

P17\0 

\0 

", "E8\0 

•I 

9 

",  "\0 

II 

9 

"\0 

P£0\0 

\0 

", "E9\0 

ll 

1 

",  " \0 

ll 

9 

"\0 

P£1\0 

\0 

",  "E10\0 

II 

1 

", "Ell \0 

ll 

9 

"\0 

P£9\0 

\0 

", "C3\0 

II 

1 

", "C4\0 

ii 

9 

"\0 

P30\0 

\0 

",  "E1£\0 
",  "\0 

",  " \  0 

il 

1 

"\0 

Instantaneous,  cumulat 


H  1  Cl 
1  r  t 


ve,  and  full  cumulative  workloads,  and 


average  full  cumulative  workload. 
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float  wloadC10003,  cwload C10001 , fcwload C 100] , afcwload 


» 


FIGURE  14  (CONT'D) 
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5.  PRELIMINARY  GUIDELINES  FOR  HUMAN  PERFORMANCE  ENHANCEMENT 

Enhancement  of  human  performance  within  a  man-machine  environment  system 
context  requires,  in  general,  one  or  more  of  the  following: 

(1)  Training,  to  overcome  skills  deficiencies. 

(2)  Task  Reallocation,  to  ensure  fair  distribution  of  workload. 

(3)  Man-machine-interface  (MMI)  Redesign,  to  simplify  the 
operator/maintainers  interaction  with  the  equipment. 

(4)  Aiding,  to  reduce  operator  burden  and  enhance  operator 
performance. 

Within  the  context  of  human  factors  and  human-related  problems  in 
maintainability  of  propulsion  systems  each  of  the  above  can  be  applicable. 
Exactly  which  is  warranted  in  a  specific  context  is  shown  in  Figure  15. 

Training  is  warranted  when  the  maintainer/operator  has  certain  skill 
deficiencies  that  can  be  "trained  out."  Task  Reallocation  may  be  warranted 
when  there  is  unequal  distribution  in  workloads  or  when  workload  of  an 
individual  operator  Is  excessively  high  or  low.  However,  due  to  equipment 
(MMI  constraints)  and/or  manpower  resource  availability,  task  reallocation 
may  not  always  be  feasible.  MMI  redesign  (or  consideration  of  other  MMI 
options)  is  another  alternative  that  may  be  viable,  especially  when 
operators  are  reasonably  trained,  their  workload  is  not  excessive,  but 
their  performance  is  deficient.  Finally,  aiding  is  the  only  recourse  when 
neither  redesign  nor  reallocation  is  feasible,  operators  are  trained,  but 
workload  is  excessive  and  performance  is  deficient. 

Proper  training  receive  priority  but  may  not  be  always  feasible.  Task 
reallocation.  If  necessary  and  feasible,  is  a  straightforward  solution  to 
performance  problems  resulting  from  an  individual's  workload  being 
excessive  or  deficient.  MMI  redesign  can  have  minimal  or  prohibitive  cost 
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READ: 

TASK  10 

TASK  REPRESENTATION 
MM  I  OPTION 

current  OPTION 


and  time  impacts.  Further,  redesign  of  the  MMI,  while  perhaps  desirable 
may  not  appreciably  reduce  operator  workload.  Aiding  typically  is  the  only 
recourse  available  when  the  others  fail.  However,  aiding  typically  implies 
additions/changes  to  software  and  occasionally  to  hardware,  too.  The 
overall  approach,  when  partial  automation  or  aiding  is  necessary,  is  shown 
in  flowchart  form  (Figure  15).  This  figure  actually  provides  an  integrated 
approach  for  determining  which  alternative  is  warranted  and  when.  Figure 
16  provides  the  overall  concept  for  aid  selection  in  flowchart  form. 


FIGURE  16. 

AID  SELECTION  CONCEPT 


69 


6. 


CONCLUSIONS  &  FUTURE  DIRECTIONS 


This  study  has  resulted  in  a  systematic  model-based  methodology  for 
analyzing  operator/maintainer-related  maintainability  problems  associated 
with  shipboard  propulsion  plants  in  general  and  the  DD963  class  gas  turbine 
system  in  particular.  It  has  been  shown  that  within  this  framework  several 
types  of  human-related  problem  areas  can  be  predicted/identified.  These 
include:  (1)  inadequate  communication  in  cooperative  maintenance  tasks; 

(2)  gaps  in  operator/maintainer  knowledge;  (3)  operator  slips;  (4) 
inadequate  MMI  design.  It  has  been  suggested  that  problems  in  cooperative 
maintenance  tasks  can  often  be  alleviated  by  proper  and  timely  presentation 
of  maintenance-related  information.  It  has  been  shown  that  the  MPN 
representation  lends  itself  to  problem  identification,  performance 
evaluation  and  computer-aided  human  factors  design.  At  the  heart  of  this 
approach  is  a  workload  prediction/estimation  process,  the  results  of  which, 
coupled  with  operator  performance  data,  can  be  used  to  provide  the 
necessary  insights  in  determining  whether  MMI  redesign,  task  reallocation 
or  aiding  is  warranted. 

In  addition  to  succinctly  capturing  the  input/output  data  description,  a 
structural  MPN  model  can  also  provide  some  indication  of  the  interactions 
among  perceptual,  cognitive,  and  motor  processes.  In  the  current  model,  we 
have  assumed  that  maximal  workload  associated  with  concurrent  activities  is 
additive.  In  future  work,  we  hope  to  introduce  the  notion  of  a  finite 
resource  pool,  identifying  resources  required  by  each  kind  of  activity  as  a 
means  for  determining  the  total  workload  associated  with  various  kinds  of 
concurrent  activities.  Combined  with  model  synthesis  techniques  and 
equivalence  structures  (e.g.,  Gelenbe  and  Mltranl,  1980),  a  structural 
model  could  potentially  provide  both  predicted  performance  characterization 
and  control  of  a  well -represented  maintenance  task. 
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Future  work  in  this  problem  area  will  include  the  analysis  of  maintenance 
data  from  historical  Navy  data  bases  to  confirm  predicted  problem  areas  and 
provide  qualitative  evaluation.  Also  field  studies  will  be  conducted  to 
collect  human  performance  data  which  will  be  used  to  validate  the  current 
model.  In  addition,  the  execution  of  the  MPN  along  with  performance 
measures  will  be  portrayed  on  a  graphics  system  under  microcomputer  control 
to  evaluate  the  model  for  its  potential  as  a  system  design  tool.  The 
overall  approach  will  be  applied  to  identify  specific  situations  within  the 
selected  problem  domain  where  aiding  is  not  just  desirable  but  necessary 
for  adequate  man-machine  performance.  Finally,  candidate  maintainability 
aids  and  MM I  redesign  requirements  for  current  and  future  GT  systems  will 
be  suggested. 
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Appendix  A 


The  Petri  Net 


Petri  nets  are  versatile  modelling  devices  for  studying  the  structure  and 
control  of  concurrent  processes.  Petri  nets  originated  in  petri's 
dissertation  "Communication  with  Automata"  (1962),  and  have  been  refined 
and  developed  by  Holt,  Commoner,  and  others  (Holt  et  al ,  1968,  197U; 
Commoner  et  al ,  1971).  Petri  nets  and  related  graph  models  have  been  used 
for  modelling  a  wide  variety  of  systems  from  computers  to  social  systems 
such  as:  parallel  computation  (Miller,  1973  and  Agerwala,  1974), 

asynchronous  process  corrdination  (Noe,  1971  and  Thomas,  1976),  knowledge 
representation  (Genrich  et  al ,  1976;  Zisman,  1978;  and  Jantzen,  1979), 
language  formulation  (Ginsburg,  1966  and  Oberquelle,  1979),  legal  systems 
(Meldman,  1971,  1978)  man-machine  systems  (Meldman,  1977),  and  human 
information  processing  activities  (Schumacker  and  Geiser,  1978). 

The  properties,  concepts,  and  techniques  of  Petri  nets  are  currently  being 
developed  and  expanded  in  a  search  for  natural,  simple  and  powerful  methods 
for  describing  and  analyzing  the  flow  of  information  and  control  in 
systems,  particularly  systems  that  may  exhibit  asynchronous  and  concurrent 
activities  (Petri,  1979;  Peterson,  1980).  The  major  use  of  Petri  nets  has 
been  the  modelling  of  systems  of  events  in  which  it  is  possible  forsome 
events  to  occur  concurrently  but  there  are  constraints  on  the  concurrence, 
precedence,  or  frequency  of  these  occurrences.  In  the  words  of  Miller 
(1973): 

"A  Petri  net  is  a  graphical  representation  with  directed  edges 
between  two  different  types  of  nodes.  A  node  represented  as  a 
circle  is  called  a  place  and  a  node  represented  by  a  bar  is 
called  a  transition.  The  places  in  a  Petri  net  have  the 


capaoility  of  hiding  tokens.  For  a  given  transition,  tnose 
places  that  have  edges  directed  into  the  transition  are  called 
input  places  and  those  having  edges  directed  out  of  tnis 
transition  are  called  output  places  for  the  transition.  If 
all  the  input  places  for  a  transition  contain  a  token,  then 
the  transition  is  said  to  be  active.  An  active  transition  may 
fire.  The  firing  removes  a  token  from  each  input  place  and 
puts  a  token  on  each  output  place.  Tnus,  a  token  in  a  place 
can  be  used  in  the  firing  of  only  one  transition.  A  simple 
example  of  a  Petri  net  is  shown  in  Figure  A-i.  Fiere  tokens 
are 


Figure  A-l.  A  Sample  Petri  Met 

shown  as  black  dots.  The  starting  condition  has  a  token  only 
in  Place  PI.  The  activity  of  the  net  (or  process)  is  then 
described  by  the  successive  firings  of  transitions.  In  this 
example,  T1  can  fire  followed  by  12  and  T3.  Unly  after  both 
T2  <d  T3  have  fired  are  T4  and  Tb  active.  Either  T4  or  Tb 
can  fire  but  not  both.  When  either  T4  or  Tb  fires  it  brings 
tne  net  back  to  its  starting  condition  and  the  process  is 
ready  to  repeat." 
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We  note  here  that  the  structure  of  a  Petri  net  is  a  directed  bipartitle 
graph  (Deo,  1973),  consisting  of  the  two  types  of  vertices  called  places 
(P’s)  and  transitions  (T's).  In  order  to  simulate  the  dynamic  behavior  of 
a  petri  net,  each  place  is  marked  (assigned  with  a  nonnegative  number  of 
tokens).  We  may  think  of  tokens  as  representing  data  itmes  or  as  holding 
some  conditions  represented  by  places.  The  initial  distribution  of  tokens 
on  places  may  be  regarded  as  the  initial  condition,  and  is  called  the 
initial  marking  or  state.  A  Petri  net  executes  by  firing  transitions.  A 
transition  is  said  to  be  finable  (or  enabled)  if  each  input  place  of  the 
transition  is  marked  with  at  least  one  token.  A  firable  transition  may  be 
chosen  to  fire.  The  firing  of  a  transition  consists  of  removing  one  token 
from  each  of  its  input  places,  and  adding  one  token  to  each  of  its  output 
places.  We  may  think  of  a  firing  as  an  event  which  may  take  place  if 
certain  conditions  are  satisfied.  Each  firing  will  cause  the  old 
conditions  to  cease  and  new  conditions  to  hold,  and  the  total  number  of 
tokens  in  a  Petri  net  may  change  after  each  firing.  Note  that  it  is  not 
necessary  to  fire  all  firable  transitions,  although  only  the  firing  of  a 
firable  transition  is  legal. 
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Maintenance  Task  Selection 


The  criteria  established  for  system  and  subsystem  selection  are  those 
expressed  as  follows: 

(1)  Candidate  systems  shall  be  characteristic  of  current  and 
future  maintainability  requirements. 

(2)  Candidate  subsystems  shall  manifest  event  driven  activities 
involving  concurrent  and  coordinated  maintainer/operator 
participation.  Participation  shall  include  recognition  and 
detection  of  performance  characteristics  and  require  a 
combination  of  skill,  rule,  and  knowledge  based  actions. 

(3)  Candidate  system  performance  shall  impact  platform  mission 
performance. 

(4)  Operating  procedure  requirements  for  candidate  systems  and 
subsystems  shall  be  sufficiently  complex  to  involve  the  human 
factor  problems  of  inappropriate  task  assignments  or  task 
loading  and  the  effects  of  inadequate  knowledge. 

(5)  The  maintainability  procedures  shall  permit  a  diversity  of 
outcomes  with  optimal  and  suboptimal  results.  Procedures 
shall  be  sufficiently  complex  to  permit  operator  caused 
equipment  failure. 

(6)  Candidate  systems  and  subsystems  shall  be  adaptable  to 
automation  aids  for  event  and  activity  interaction  between  the 
system  and  the  operator. 


Discussions  with  Navy  Personnel  and  a  review  of  ONR-NADC  activities  and 
responsibilities  in  relation  to  the  selection  criteria  has  resulted  in  one 
prime  candidate  system:  the  LM250U  Propulsion  Gas  Turbine  module  as 
configured  for  the  DD963  class  of  ship.  Candidate  subsysems  include  the 
Gas  Turbine  Module  (GTM)  fuel  oil  system  and  the  lubrication  system.  The 
discussion  of  selection  rationale  follows  the  criteria  format  established 
in  the  paragraph  above. 

(1)  The  LM2500  Propulsion  Gas  Turbine  module  (GTM)  can  be  found  on 
three  classes  of  naval  combatants; 

(a)  Spruance  (DD963)  class, 

(b)  Oliver  Hazard  Perry  (FFG  7)  class, 

(c)  Pegasus  (PHM1)  class. 

Future  ship  classes  to  use  the  GTM  for  main  propulsion  will  be 
the  Ticonderoga  (CG  47)  class  currently  authorized  for  21 
ships  through  FY  1986  and  an  undetermined  number  of 
undesignated  FFX  and  DDGX  vessels. 

By  1988,  five  years  hence,  it  is  reasonable  to  project  that  of 
all  surface  combatants  (CG,  DDG,  DD  and  FF),  48  percent  will 
be  GTM  powered  and  that  92  percent  all  of  that  group  which  are 
15  years  old  or  newer  will  be  GTM  powered.  Of  all  GTM  powered 
tonnage,  66  percent  will  be  DD  963  power  plant  configured. 

In  light  of  the  above,  the  DD  963  GTM  is  preeminently 
characteristic  of  both  current  and  future  maintainability 
requirements. 


(2)  The  GTM  is  the  prime  power  source  for  propulsion.  The  DD963 
propulsion  system  requires  4  GTM's  as  shown  in  Figure  B-l. 
The  GTM's  power  each  of  the  ship's  two  propulsion  shafts  as 
shown  in  Figure  B-2.  Failure  of  a  gas  turbine  and  any  of  its 
major  subsystems  results  in  a  direct  loss  of  propulsion 
horsepower  capacity. 

(3)  Supporting  the  operation  of  the  gas  turbine  are  two  major 
subsystems.  The  lubrication  system  and  the  fuel  oil  system 
are  both  integral  subsystems  of  the  gas  turbine,  and  function 
continuously  during  power  plant  operation. 

(a)  Background:  The  GTM  is  a  variant  General  Electric  TF39 
and  CF6-6  engine  which  power  the  Lockheed,  USAF/C5A  and 
the  McDonnell  Douglas  DC-10  aircrafts.  The  engine  is 
composed  on  an  axial  gas  generator  which  contains  a 
sixteen  stage  compressor,  a  combustor  section  and  a  two 
stage  drive  turbine  coupled  to  the  Main  Reduction  Gear 
Assembly.  Figure  B-3  shows  the  gas  turbine  in  its 
shipping  frame  and  Figure  B-4  shows  the  gas  generator 
and  power  turbine  section  of  the  gas  turbine.  The  two 
sections  assemble  at  the  bolt  rings  shown  by  the 
arrows. 

(b)  Lubrication  System:  The  GTM  is  supported  by  a 
lubrication  system  which  is  isolated  from  the  ship's 
main  lubrication  system.  Unique  lubricants  required 
for  the  high  temperature  of  operation  necessitate  this 
arrangement.  One  Lube  Storage  and  Conditioning 
Assembly  (LSCA)  supports  every  two  GTM's  as  shown  in 
Figure  B-l. 
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FIGURE  B-2A. 

DISTRIBUTION  OF  PROPULSION  EQUIPMENT 
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FIGURE  B-2B. 

SPACE  LOCATIONS  WITHIN  THE  DD963/CG47  HULL  CONFIGURATION 


FIGURE'  B-4A.' 
GAS  GENERATOR 
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FIGURE  B-4B. 
POWER  TURBINE 


The  portions  of  the  gas  turbine  which  require 
lubrication  and  schematic  diagram  of  the  system  are 
shown  in  Figure  B-5.  The  lube  pump  which  pressurizes 
oil  flow  to  the  bearings,  and  the  scavenge  pump  which 
extracts  oil  from  the  bearing  sumps,  and  the  accessory 
gear  drive  are  mounted  on  the  accessory  gear  drive. 
The  LSCA  cools  the  oil  via  a  heat  exchanger  which  uses 
the  ships  main  lube  oil  as  a  collant. 

The  lubrication  system,  however  important  to  system 
operation,  provides  very  few  opportunities  for  operator 
participation  beyond  monitoring  temperatures  pressures 
and  fluid  level.  System  design  provides  for  a  direct 
pressure  and  flow  relationship  to  the  gas  generator 
speed.  The  system  exhibits  no  operational  dynamics  and 
requires  few  knowledge  based  actions  on  the  part  of  the 
operator. 

(c)  Fuel  System:  The  fuel  system  of  the  GTM  performs 
multiple  functions  in  maintaining  control  of  the  gas 
generator's  operation.  The  primary  cause  of  engine 
shutdown  is  compressor  stall,  which  results  in  a  "frame 
out,"  an  interruption  of  air  flow  to  the  combustor 
which  results  in  a  loss  of  combustion.  Seventy  percent 
compressor  stall  at  various  speeds  during  the  gas 
generator's  phases  can  be  fixed  by  adjusting  the 
compressor  station  blades  (inlet  through  stage  six). 
This  adjustment  is  referred  to  as  "varying  the  angle  of 
attack,"  and  is  done  for  the  same  reason  that  an 
aircraft  must  balance  its  speed  and  angle  of  attack  to 
prevent  wing  lift  stall. 
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FIGURE  B-5A. 

POINTS  OF  LUBRICATION 


FIGURE  B-5B. 

LUBRICATION  FUNCTIONAL  DIAGRAM 
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The  angle  of  attack  must  be  adjusted  continuously 
throughout  the  operating  speed  and  power  range.  In 
conjunction  with  fuel  flow  to  the  combustor,  the  angle 
of  attack  controls  the  rate  of  acceleration  and 
deacceleration  and  permits  a  degree  of  engine  control 
flexibility  that  the  gas  generator  would  not  otherwise 
have. 

Fuel  pressure  is  ported  to  the  hydraulic  control 
cylinder  which  controls  the  variable  stator  vane 
actuators.  Establishing  correct  flow  rates,  pressures 
and  receiving  feedback  signals  is  the  function  of  the 
main  fuel  control.  Figure  B-6  shows  the  fuel  system 
flow,  sensors,  and  feedback  elements  of  the  fuel 
control  system. 

The  fuel  system  is  an  integral  portion  of  the  gas 
turbine  electronic  power  control  system.  It  should  be 
remembered  that  the  GTM  is  comprised  of  the  gas 
generator  and  an  independent  power  turbine.  The  fuel 
system  therefore  functions  as  part  of  the  overall 
system  to  control  output  shaft  torque  and  rotational 
speed.  Figure  B-7  describes  in  general  the  functions 
of  the  Free  Standing  Electronics  Enclosure  (FSEE), 
which  continuously  computes  fuel  adjustments  based  upon 
power  command  and  gas  turbine  condition  sensor  signals. 
The  FSEE  is  shown  in  Figure  B-l. 

The  fuel  system  is  an  excellent  candidate  for  subsystem 
selection  due  the  variety  of  functions  performed.  It 
satisfies  the  criteria  established  earlier  due  to  the 
following: 
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FUEL  CONTROL 


FIGURE  B-6. 

FUEL  SYSTEM  FUNCTIONAL  DIAGRAM 


FIGURE  B-7, 

GAS  TURBINE  ELECTRONIC  POWER  CONTROL 
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1)  provides  continuous  dynamic  control  of  the  gas 
generator  fuel  flow  and  compressor  air  flow  to 
maintain  proper  combustion; 

2)  functions  as  a  major  element  in  the  power  turbine 
output  control  system  with  multiple  levels  of 
feedback  control ; 

(3)  is  capable  of  operating  at  a  suboptimal  level  such 
that  operator  diagnostics  are  required  to  identify 
and  correct  performance. 

(4)  The  operating  system  for  GTM  powered  ships  of  the  DD963  class 
and  above  provide  three  levels  of  automatic  control.  Since 
the  FSEE  is  an  essential  portion  of  all  GTM  operation,  a 
manual  mode  of  GTM  operation  is  not  an  option. 

(a)  The  GTM  and  the  remainder  of  the  propulsion  plant  can 
be  operated  from  four  locations:  the  bridge  (highest 
level  of  abstraction  and  ship  control  decision  level), 
the  central  control  station  (direct  engineering  control 
level  but  isolated  from  the  propulsion  equipment),  and 
the  propulsion  local  operating  equipment  (PLOE)  station 
(direct  GTM  control  capable  of  direct  man-machine 
interface  for  operator  recognition  and  detection). 
Figure  B-2B  shows  the  location  within  the  ship  of  each 
location.  Figure  B-8  shows  the  overall  Engineering 
Control  and  Surveillance  System  (ECSS). 
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ENGINEERING  CONTROL  AND  SURVEILLANCE  SYSTEM  (ECSS) 


(b)  All  three  levels  of  control  are  continuously  manned 
during  operation  and  have  hierarchical  operating 
procedures  for  propulsion  plant  control.  Figure  B-9 
displays  signal  flow  during  bridge  operation  of  both 
propulsion  plants.  Malfunctions  or  out-of-limits 
parameters  may  be  observed  at  both  the  central  control 
station  and  the  engine  rooms  via  the  ECSS  equipment 
installed  in  each  space;  however,  direct  observation  is 
possible  only  at  the  GTM.  Such  a  situation  becomes 
critical  at  the  inception  of  failure  of  equipment  such 
as  the  fuel  system. 

(c)  Suboptimal  operation  of  the  MFC  would  likely  result  in 
transient  stall  conditions  in  the  gas  generator. 
Current  diagnostic  guidelines  state  that  such 
conditions  may  only  be  apparent  at  the  local  operating 
station.  The  event  structure  for  such  a  situation 
would  be:  (i)  bridge  has  propulsion  control  with  no 
knowledge  of  any  plant  conditions,  (ii)  central  control 
station  has  full  plant  monitoring  responsibility  and 
only  monitors  the  bridge’s  control  of  propulsion 
operation,  and  (iii)  the  local  operator  monitors 
operation  of  the  GTM  in  conjunction  with  other  engine 
room  equipment  and  has  no  function  in  direct  propulsion 
control . 

(d)  A  variety  of  task  loadings  and  assignments  are  possible 
within  the  various  model  of  operating  procedures.  The 
opportunities  for  human  factor  problems  exist  due  to 
isolated  operation  of  equipment,  monitoring  of 
equipment  operation  with  limited  sensor  display. 
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FIGURE  B-9. 

ECSS  CONTROL  AND  FEEDBACK  SIGNAL  SYSTEM 


responsibility  to  monitor  without  authority  to  control, 
and  a  three  level  communication  network  consisting  of 
control  console  information  and  verbal  information. 

(5)  Current  diagnostic  guides  are  definite  regarding  many  malfunc¬ 
tions  of  the  GTM,  and  have  straightforward  decision  tree 
checklists  to  follow  in  the  event  of  out-of  limits  operation. 
In  those  cases  involving  gas  generator  stall,  the  recommended 
actions  are  more  general  and  require  maintainer  knowledge 
based  actions.  It  is  significant  to  note  that  at  the  most 
likely  time  of  malfunction  the  operator  will  be  two  levels  of 
abstraction  from  the  maintainer. 

The  above  conditions  lead  to  complex  event  structures 
involving  communications,  changes  in  equipment  control  and 
difficult  decisions.  Under  procedural  guides  known  at  this 
time,  this  situation  could  result  in  unnecessary  failure. 

(6)  The  GTM  as  discussed  above  requires  electronic  automation  for 
its  immediate  operation  and  control.  The  ECSS  as  shown  in 
Figure  B-8  and  B-9  is  a  complex  electronic  display  and  control 
system.  Given  the  level  of  automation  to  which  the  propulsion 
plant  is  already  designed,  it  is  considered  very  likely  that 
further  automation  could  be  developed  to  aid  in  the  operation 
of  the  system. 

Both  the  LM2500  lube  oil  and  fuel  system  of  the  propulsion  plant  GTM  and 
ECSS  as  it  is  configured  on  the  0D963  class  vessel  are  considered  to  be 
satisfactory  candidates  for  the  subject  study.  However,  the  lube  oil 
system  is  more  complicated  and  contributes  to  frequent  maintenance 
problems.  The  problems  associated  with  the  lube  oil  system,  especially  the 
main  reduction  gear  lube  oil  system,  are  time-stressed,  and  cause  greater 


damage  to  the  gas  turbine  plant,  which  often  leads  to  total  disruption  of 
the  ship's  propulsion  function.  Consequently,  since  the  lube  oil  system 
poses  a  more  severe  maintainability  problem  to  the  Navy  maintenance 
personnel,  it  was  selected  for  analysis  of  human-related  maintainability 
problems. 
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Appendix  C 


Human  Behavior  Classification 


Some  basic  ideas  about  human  behavior  and  human  thinking  are  inevitably 
necessary  when  automation  is  considered.  One  might  think  of  activities 
like  teaching,  training,  task  allocation  between  man  and  machine, 
information  presentation  to  operators,  and  so  on.  When  designing 
automation,  all  too  often  little  regard  is  given  to  human  behavior  and 
human  thinking.  This  leads  to  negative  benefits.  Even  a  relatively  simple 
model  of  human  behavior  is  better  than  none  at  all.  To  this  end,  a 
convenient  means  of  looking  at  human  behavior  is  provided  by  Rasmussen 
(1978).  Rasmussen  distinguishes  three  different  categories  of  human 
behavior  in  controlling  or  supervising  tasks:  skill-based,  rule-based  and 
knowledge-based  behavior.  These  categories  are  depicted  in  Figure  C-l, 
which  shows  a  scheme  of  the  major  ways  in  which  information  from  sensory 
inputs  are  converted  into  actions.  The  characteristics  of  each  of  these 
behavior  categories  along  with  examples  of  each  are  given  in  Table  C-l. 


Figure  C-l.  Rasmussen's  Behavior  Taxonomy 
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OPERATOR  BEHAVIORS  IN  ENGINE  ROOM  TRANSIENT  MANAGEMENT 


BEHAVIOR 

CHARACTERISTICS 

EXAMPLES 

Skill -Based 

•  little  or  no  conscious  attention 
and  effort 

•  automated  or  nearly  automated 
actions 

using  tools, 

reading 

gauges 

Rule-Based 

•  more  mental  effort 

•  pre-specified  but  not  necessarily 
formalized  actions 

•  rules  can  be  empirically  derived 
(trial  &  error),  formed  by  causal 
reasoning  or  prescribed  as  formal 
work  instructions 

•  recognizable  situations/states  can 
be  directly  mapped/associated  with 
specific  actions 

•  tempi  ate. matching 

fault 

correction 

Knowledge-Based 

•  highest  mental  effort 

•  problem  solving 

•  requires  conscious  attention 

•  higher-level  thinking  using 
fundamental  principles  and 
knowledge  to  deduce  and/or 
infer  which  actions  to  take 

fault 

diagnosis 

Skill -Based  Behavior.  The  lowest  level,  skill-based  behavior,  is  the  area 
of  automated  or  nearly  automated  actions  like  walking,  bicycle  riding,  and 
so  on.  They  require  little  or  no  conscious  attention  and  effort.  For  an 
experienced  operator,  using  tools  and  reading  gauges  falls  into  this 
category. 

Rule-Based  Behavior.  At  the  middle  level,  the  level  of  rule-based 
behavior,  more  mental  effort  is  required.  Whereas  ski  11 -based  behavior  is 
typical  for  repetitive,  frequently  performed  tasks  (e.g., simple 
assembly-line  actions)  the  rule  based  behavior  is  typical  for  less  frequent 
tasks  in  a  familiar  work  environment  (e.g.,  complex  assembly-line  actions 
and  emergency  procedures  in  a  power  plant).  Rule-based  behavior  concerns 
pre-specified,  but  not  necessarily  formalized,  actions.  The  rules 
underlying  the  behavior  can  be  prescribed  as  formal  work  instructions. 
Recognizable  situations  or  states  can  be  directly  mapped  on,  or  associated 
with  specific  actions.  In  rule-based  behavior,  both  situation  and 
connected  action  are  conscious;  the  mapping  and  the  associational  rule  are 
not. 

Knowledge-Based  Behavior.  The  third,  and  highest  level  of  behavior  in 
terms  of  mental  effort  on  the  operator's  part,  is  the  knowledge-based 
level.  Quoting  Rasmussen  (198U):  "This  is  the  level  of  intelligent 

problem  solving  which  should  be  the  prominent  reason  for  the  presence  of 
human  operators  in  an  automatic  plant.  Behavior  in  this  domain  is 
activated  in  response  to  unfamiliar  demands  from  the  system.  The  structure 
of  the  activity  is  an  evaluation  of  the  situation  and  planning  of  a  proper 
sequence  of  actions  to  pursue  the  goal.  The  activity  depends  upon 
fundamental  knowledge  of  the  processes,  functions  and  anatomical  structure 
of  the  system."  Knowledge-based  behavior  involves  high-level  thinking. 
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typically  using  fundamental  principles  and  knowledge  to  deduce  and/or  infer 
which  actions  should  be  taken.  In  this  behavior-area  no  pre-specified 
guidelines  normally  exist.  All  the  stages  depicted  in  Figure  C-l  at  the 
knowledge-based  level,  have  to  be  given  conscious  attention. 

This  three-level  behavior  classification  provides  a  convenient  framework 
for  initially  analyzing  control  room  operator  tasks. 
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TIME  8 
PI 

Monitor  MRS  pressure  gauge. 

TIME  2 
« 

>  J. 

Engine  room  reports  major  lube  oil  leak  in  MRG  lube  oil  system. 

P2 

Evaluate  magnitude  and  location  of  leak. 

TIME  7 
T7 

Post  fork  leak. 

Pfl 

Inform  engine  room  of  EOCC. 

Pll 

EQW  orders  engineering  spaces  manned. 

TIME  18 
T12 

PflCC  operator  reports  to  EOU,  "No.  i  lube  oil  service  system  secured. 

No.  i  STM  stopped.  It  is  at  CCS.  No.  i  shaft  stopped  with  shaft  brake 
on.  “ 

P0  . 

Inform  engine  room  of  EOCC. 

P12 

cOU  reports  to  000,  "Major  lube  oil  leak  in  no.  i  engineroom.  No.  i 
STM  is  stopped.  ITC  is  at  CCS.  No.  i  shaft  is  stopped  with  shaft 
brake  on.  Maximum  speed  available  is  i  knots." 

TIME  21 
T13 

EPCC  operator  reports  to  EOU,  "No.  i  STS  is  stopped.  No.  i  GTS  is 
online  and  in  parallel  with  no.  i  GTG.  “ 

P0 

Inform  engine  room  of  EOCC. 

P13 

Monitor. 

TIME  22 
T14 

Engineering  spaces  report  manned. 

PS 

Inform  engine  room  of  EOCC. 

P14 

Monitor. 

TIME  £3 
T1S 

No.  i  engineroom  reports  to  EOU,  "Main  reduction  gear  lube  oil  service 
system  leak  is  isolated. " 

PS 

Inform  engine  room  of  EOCC. 

P15 

Monitor. 

TIME  24 
T16 

PACC  operator  reports  to  EOU,  “Bleed  air  secured  from  no.  i  STM  and 
isolated  from  no.  3  GTG.  " 

PS 

Inform  engine  room  of  EOCC. 

P16 

Monitor.  -  * 

TIME  £5 
T17 

Unaffected  enpineroom  reports  to  EOU,  "Bleed  air  secured  from  no.  i  GTE." 


P8 

Inform  engine  room  of  EOCC. 

P17 

Monitor. 

TIME  26 
T 18 

Mo.  i  engineroom  reports  to  EOW,  "Lube  oil  flushed  into  bilges,  covering 
with  AFFr.  11 
P8 

Inform  engine  room  of  EOCC. 

P18 

ECU  reports  to  OQD,  "Major  lube  oil  leek  in  no.  i  engineroom  is  isolated. 

Lube  oil  in  no.  i  engineroom  is  flushed  into  bilges  end  covered  with  AFFF. " 

EOW  requests  permission  from  00D  to  remove  fire  hazards  (in  accordance  with 
current  environmental  protection  requirements) . ” 

TIME  41 
T19 

□00  grants  permission. 

P8 

Inform  engine  room  of  EOCC. 

PI  9 

ECU  orders  no.  i  engineroom  to  remove  fire  hazards  (in  accordance  with  current 
environmental  protection  requirements) . 

TIME  SI 
T20 

No.  i  engineroom  reports  to  EOW,  "Fire  hazards  removed. “ 

P8 

Inform  engine  room  of  EOCC. 

P20 

EOW  reoorts  to  00D,  "Fire  hazards  removed  from  no.  i  engineroom. "  EOW  orders 
no.  i  engineroom  to  investigate  for  the  cause  of  the  casualty  using  approved 
maintenance  procedures  and  technical  manuals. 

TIME  62 

T21  1 

No.  i  engineroom  reports  to  EOW  cause  of  the  casualty  and  estimated  time  to 
repair. 

Pfl 

Inform  engine  room  of  EOCC. 

P21 

EOW  reports  to  00D  the  cause  of  the  casualty  and  estimated  time  to  repair. 

TIME  73 
T22 

Casualty  cannot  be  restored  in  a  reasonable  amount  of  time. 

PS 

Inform  engine  room  of  EOCC. 

P22 

EOW  requests  permission  from  00D  to  stop  the  ship  to  lock  no.  i  shaft. 

TIME  78 
T23 

QOD  grants  permission  to  stop  the  ship. 

pa 

Inform  engine  room  of  EOCC. 

P23 

EOW  orders  PACC  operator  to  place  the  unaffected  shaft  ITC  lever  at  ’STOP’ 
and  maintain  zero  thrust. 

TIME  93 
T24 

When  the  SHIP  SPEED  indicator  is  at  "0"  knots,  PACC  ooerator  reoorts  to  EOW, 
"ITC  lever  is  at  ’STOP’.  Maintaining  zero  thrust  on  no.  i  shaft." 

pa 

Inform  engine  room  of  EOCC. 

P24 

ECW  orders  PACC  operator  to  release  the  shaft  brake  on  the  affected  shaft. 

TIME  98 
”23 

°flCC  ooerator  reoorts  to  EOW,  "No.  i  shaft  brake  is  released. " 


Inform  enc  me  r  jora  of  EGCC. 

—  t-c 

—  i—*/ 

EGW  locus  no.  1  shaft. 

~:me  101 


Shutaown  complete. 

=3 

Inform  engine  room  of  EQCC. 

P32 

Repairs  proceedino. 

TIME  126 
“35 

Dummy  comp lata. 

T8 

Engine  room  informafl  and  rapairs  complete. 
P9 

Evaluate/ rest ora  normal  operation. 

TIME  128 
T9 

Normal  operation  restored. 

PI 


'Monitor  MRG  pressure  gauge. 


I  ME 

INST  WORKLOAD 

CUM  WORKLOAD 

0 

3. 999399e-0£ 

0.  0000008+00 

1 

3. 993999e-0£ 

9.  939999e-0£ 

«■» 

1 . 7000008+00 

2.  000000B-01 

3 

1 . 633033e+00 

1.  3000008+00 

4 

1 . 5705508+00 

3.  5330338+00 

5 

l.S12£52e+00 

5.  103583e+00 

3 

1 . 457858e+00 

6.6158358+00 

7 

1. 307107e+00 

8.  0736938+00 

8 

1. 197864e+00 

9.  3807998+00 

9 

1. 1045608+00 

1.057866e+01 

10 

1 . 424349e+00 

1. 168322e+01 

11 

1. 29305£e+00 

1.3107578+01 

12 

1. 183482e+00 

1.  4400628+01 

13 

1. 091516e+00 

1.5584108+01 

14 

1. 013858e+00 

1.6675628+01 

15 

9.47867£e-01 

1.768948e+01 

16 

8. 914£91e-01 

1.  8637348+01 

17 

8. 4£8446e-01 

1.9528778+01 

18 

8. 007475e-01 

2.  0371618+01 

19 

7. 640360e-01 

2.  1 172368+01 

20 

7. 313£0£e-01 

2.  1936408+01 

21 

7. 033785e-01 

2.2668218+01 

22 

8. l££350e-01 

2.  3371598+01 

£3 

8. 853304e-01 

2.  4187838+01 

£4 

9. 267764e-01 

2.  5073828+01 

£5 

9. 4831£5e— 01 

2.  6000S9e+01 

26 

l.£57£52e+00 

2.6948908+01 

27 

1. 058123e+00 

2.8206158+01 

28 

9. l£5631e-01 

2.  9264288+01 

£9 

8. 054643e-01 

3.0176848+01 

30 

7. 260496e-01 

3.0982308+01 

31 

6. 666££8e-01 

3.  1708358+01 

32 

6. £16803e-01 

3.2374978+01 

33 

5. 87£797e-01 

3.  2996658+01 

34 

5. 605917e-01 

3.  3583938+01 

35 

5. 395814e-01 

3.  4144528+01 

36 

5. ££781£e-01 

3.  4684108+01 

37 

5. 031£96e-0l 

3.5206878+01 

38 

4. 978560e-01 

3.  5716008+01 

33 

4. 883384e-01 

3.  6213868+01 

40 

4, 803452e-01 

3.  6702258+01 

I 


41 

5. 733929e-01 

3. 716259**01 

42 

5. 1731£3e-0l 

3. 775599**01 

43 

4. 86947 le-01 

3. 8273308*01 

44 

4. £9658 le-01 

3. 87£025**01 

45 

4. 591024e-01 

3. 9229908*01 

46 

4. 520800e-01 

3. 968900**01 

47 

4. 463702*- 01 

4. 014108**01 

48 

4. 423455*-01 

4. 058805**01 

43 

4. 335779*-01 

4. 103099*+01 

50 

4. 3664£le-01 

4. 147057e+01 

51 

5. 340151*-01 

4. 190721**01 

52 

4. 816274*-01 

4. £44122**01 

53 

4. 544365*— 01 

4. £9£285**01 

54 

4. 399150*-01 

4. 3377£B*+01 

55 

4. 317932*-01 

4.381720**01 

56 

4. 263314*— 01 

4. 424899**01 

57 

4. 237551 *-01 

4. 467592e*0 1 

58 

4.  £1 4728*-01 

4. 509967**01 

53 

4.  136S5£*-01 

4. 552114**01 

60 

4.  181831»-01 

4. 594082**01 

61 

4.  168737*-01 

4. 635901 *+01 

62 

7.  157018*-01 

4. 677589**01 

63 

6.  527352»-01 

4. 749158**01 

64 

6.  026200 e— 01 

4.  8l4432e+01 

65 

5.  6271 1 1*-01 

4.  874694*+01 

66 

5.  309184*-01 

4.930965**01 

67 

5.  055526*-01 

4.  984055**01 

68 

4.  853161S-01 

5. 034610**01 

63 

4.  631515c— 01 

5. 083 142»*01 

70 

4.  562256*- 01 

5. 130057**01 

71 

4.  458766*-01 

5. 175679**01 

72 

4.  375789*-01 

5.  220266**0 1 

73 

8.  309149*— 01 

5-  26402 4*+01 

74 

7.  608281 *-01 

5. 3471158*01 

75 

7.  001580*— 01 

5. 423198*+01 

76 

6.  476105*— 01 

5. 4932148*01 

77 

6.  020746*— 01 

5.557975**01 

78 

6. 625959*-0 1 

5. 61818£*+01 

73 

5.  783531 *-01 

5. 684441 **01 

80 

5.  23639S«-01 

5.  7422768*01 

81 

4. 853458*— 01 

5.  7946408*0 1 

82 

4.  5££967e-01 

5. 8431748*01 

S3 

4.  34U36*-01 

5. 888644**01 

84 

4. 1564£3*-01 

5.  932255**01 

as 

4. 001£30*-01 

5. 973819*+01 

86 

3. 863922*-01 

6.  0 1 3836*+0 1 

87 

3. 756813*-01 

6. 05£534**01 

88 

3. £59131 *-01 

6. 090102*+01 

89 

3. 574488*-01 

6.  1£6693*+01 

90 

3. 50099£»-01 

6. 16£438**01 

91 

3. 437093*-01 

6.  197448**01 

92 

3. 381490C-01 

6. 231819**01 

93 

4. 333079*— 01 

6. 26S633**0 1 

94 

3. 790911 *-01 

6. 3089648*01 

95 

3. 504167*-01 

6. 346873*+01 

96 

3. 347 141 *-01 

6.381915**01 

97 

3. 256719*-01 

6. 415385**01 

98 

4. 201 1 19*-01 

6.447952**01 

39 

3. £64253*-01 

6. 4899638*01 

100 

3. 387307*-01 

6. 526605**01 

101 

4. 2428£5*-01 

6.  5604648*01 

102 

3. 66425 le-01 

6.  602911**01 

103 

3. 3696938-01 

6.  6395548*01 

104 

3. £17809*-01 

6.  673251 **01 

105 

3. 137842*-01 

6.  705428*+01 

106 

3. 094338e-01 

6.  736806**01 

2.  8£3307b“01 
3. 854337e-81 

2.  844483e-01 

3.  8374£3b-81 
3. 83£143e-81 
3.8£7838b-81 
3. 0£4385b-81 
3. ®£1489b-®1 
3. 818831b-01 
3. 81 ££3£e-81 
3. 814£97b-01 
3. 813883e-81 
3. 81 1317B-81 
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Appendix  E 


Existing  U.S.  Navy  Maintenance  Data  Sources 

To  improve  design  for  maintainability  and  to  verify  the  proposed  approach 
it  is  necessary  to  have  access  to  a  systematic  collection  of  pertinent 
information  about  maintenance  tasks,  the  equipment  to  which  those  tasks 
relate,  and  the  personnel  performing  them.  Relevant  maintainabi 1 ity 
information  includes  the  following: 

(1)  The  classes  of  maintenance  tasks  that  apply  across  types  of 
Navy  Gas  Turbine  propulsion  equipment  and  the  specific  types 
of  equipment  to  which  they  apply. 

(2)  The  relative  importance  of  the  classes  of  maintenance  tasks 
across  all  types  of  gas  turbine  related  equipment. 

(3)  The  difficulty  of  performing  each  class  of  maintenance  task 
across  types  of  equipment. 

(4)  The  types  of  maintainability  problems  that  affect  each  class 
of  maintenance  tasks  across  all  types  of  equipment  and  for 
each  type  of  equipment. 

(b)  The  severity  of  each  maintainabi 1 ity  problem  across  classes  of 
maintenance  tasks  and  types  of  equipment  and  for  each  class  of 
maintenance  task  and  specific  type  of  equipment. 

The  above  information  is  currently  available  in  part  in  U.S.  Navy 
maintenance  data  bases.  In  addition,  other  types  of  information,  which 
could  be  transformed  into  the  required  types,  are  available  in  these  data 
bases.  This  section  consists  of  a  matrix  of  U.S.  Navy  maintenance  data 
sources  by  their  contents,  and  the  utility  of  their  contents  for  this 
program;  plus  a  general  discussion  of  the  nature  of  the  more  significant 
data  sources  that  have  been  identified. 


1. 


Overview  of  Navy  Maintenance  Data  Sources 


The  surface  and  subsurface  U.S.  Navy  has  one  major  maintenance  data 
management  system— the  Maintenance  Data  System  (MDS)  module  of  the  Ship's 
Maintenance  and  Material  Management  (3M)  System.  MDS  is  used  to  manipulate 
and  manage  a  series  of  primary  data  sources.  In  addition,  the  surface  and 
subsurface  Navy  has  a  group  of  non-MDS  primary  data  sources.  Navy  air  has 
one  major  data  management  system  that  may  be  pertinent  to  the  question  of 
maintainability--the  Aircraft  Deficiency  Storage,  Tracking  and  Retrieval 
System  (ADSTARS).  The  primary  data  sources  that  make  up  MDS,  as  well  as 
the  non-MDS  sources— are  of  importance  because  of  the  possible  utility  of 
their  contents  for  the  maintainability  design  program.  ADSTARS'  importance 
is  based  on  the  potential  similarity  of  the  maintainability  problems  to 
ship  problems. 

This  section  will  describe  the  most  potentially  useful  data  sources, 
indicate  their  differences  and  similarities,  estimate  their  utility  for 
this  program,  and  specify  where  they  can  be  accessed. 

2.  MDS  Data  Sources 


MDS  data  sources  that  have  significant  utility  for  this  program  are  4790/2 
series. 


2.1  OPNAV  479Q/2K.  OPNAV  4790/2K  is  the  primary  data  source  of  MDS. 
It  is  a  standard  form  that  is  filled  out  when  a  maintenance  action  is 
performed.  It  includes  the  following  information: 


(1)  Identification  of  the  equipment  that  was  maintained. 

(2)  The  class  of  maintenance  job(s)  performed  on  the  equipment. 

(3)  The  nature  of  the  equipment  failure. 

(4)  The  reason  for  the  equipment  failure. 
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(5)  Any  alteration  of  the  equipment  that  took  place. 

(6)  The  priority  of  the  maintenance  action. 

(7)  The  rating  (El,  E2,  etc.)  of  the  maintenance  personnel. 

(8)  The  time  required  to  troubleshoot  the  problem. 

(9)  The  number  of  man  hours  required  to  perform  the  maintenance 
action. 

(10)  The  real  time  required  to  perform  the  maintenance  action. 

(11)  The  problems  encountered  in  performing  maintenance. 

(12)  The  hazards  encountered  in  performing  maintenance. 

The  information  contained  in  the  various  OPNAV  4790/2K's  should  be 
extremely  useful  for  this  program.  It  provides  the  classes  of  maintenance 
jobs  and  types  of  equipment  to  which  those  jobs  apply.  Depending  upon  the 
distinction  of  jobs  versus  tasks,  this  should  greatly  aid  the  process  of 
determining  the  classes  of  maintenance  tasks  or  activities  that  apply 
across  types  of  Navy  equipment  and  the  specific  types  of  equipment  to  which 
they  apply.  The  priorities  of  various  maintenance  actions  should  be 
equivalent  to  the  relative  importance  of  the  classes  of  maintenance  jobs. 
The  required  maintenance  times,  the  required  number  of  maintenance 
personnel,  and  the  ratings  of  those  personnel  should  provide  a  basis  for 
determining  an  estimate  of  job  difficulty.  The  descriptions  of  the 
problems  and  hazards  encountered  in  maintenance  performance  may  prove 
useful  in  defining  the  maintainability  problems  that  apply  to  each 
maintenance  job  and  type  of  equipment. 

There  are  three  principal  difficulties  in  the  use  of  OPNAV  4790/2K: 

(1)  It  is  based  on  maintenance  jobs  rather  than  tasks,  and  they 
may  be  at  too  gross  a  level  for  full  utility. 

(2)  Problems  and  hazards  may  either  be  absent,  or  not  translatable 
into  maintainability  problems. 

(3)  There  is  no  check  on  the  accuracy  of  recorded  data. 
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However,  these  three  difficulties  with  OPNAV  479G/2K  should  not  prevent 
this  data  source  from  being  extraordinarily  useful.  It  is  expected  that 
OPNAV  4790/2K  should  be  one  of  the  basic  data  sources  for  this  program. 

2.2  Other  Data  Sources.  Other  data  sources  (Master  Job  Catalog, 
Planned  Maintenance  System  Records,  OPNAV  4790/2B,  2P,  2F,  2R,  and  2Q,  Ship 
Force  Work  List)  may  be  useful,  but  are  based  on  reformatting  of  the  same 
information  as  those  previously  described. 

3.  Non-MDS  Data  Sources 


There  are  a  large  number  of  potentially  pertinent  data  sources  that  are  not 
part  of  MDS.  There  are  four  categories  of  non-MDS  data  sources  that  have 
the  greatest  potential  to  aid  this  program  by  providing  maintainability 
problems  specific  to  pieces  of  equipment  and/or  maintenance  tasks.  These 
four  categories  of  data  sources  are: 

(1)  Equipment  Logs  and  Operating  Records. 

(2)  Inspection  and  Test  Reports. 

(3)  Summary  Maintenance  Condition  and  Readiness  Reports. 

(4)  Safety  Hazard  Reports. 

Other  categories  of  non-MDS  data  may  prove  useful,  but  these  four  appear  to 
have  the  highest  probability  of  providing  the  elusive  maintainability 
problem  data.  It  is  unlikely  that  the  non-MDS  data  sources  will  provide 
information,  other  than  maintainability  problems,  that  is  not  available 
from  the  MDS  sources. 
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3.1  Equipment  Logs  and  Operating  Records.  This  category  includes  a 
number  of  data  sources.  The  types  of  data  sources  that  currently  appear  to 
be  the  most  pertinent  to  this  program  include: 

(1)  Engineering  Log. 

(2)  Gas  Turbine  Module  (GTM)  Operating  Records. 

(3)  Engine  Trend  Analysis  Record. 

These  three  types  of  data  sources  appear  to  be  pertinent  to  this  program, 
but  it  will  be  necessary  to  examine  a  reasonable  sample  of  the  others  to 
determine  if  they  contain  maintainability  problems.  The  accessibility  to 
the  data  sources  may  present  a  problem. 

3.2  Inspection  and  Test  Reports.  This  category  includes  a  minimum  of 
2b  types  of  data  sources.  Of  these  25,  the  types  of  data  sources  that 
currently  appear  to  be  pertinent  to  this  program  are: 

(1)  Engineering  Trial  Reports. 

(2)  Propulsion  Examining  Board  (PEB)  Light-Off  Examination 
Reports. 

(3)  PEB  Operating  Propulsion  Plant  Examination  Reports. 

(4)  INSURV  Inspection  Reports. 

These  four  types  of  data  sources  should  contain  any  maintainability 
problems,  dealing  with  propulsion  units,  in  this  category  of  non-MDS  data. 
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3.3  Summary  Maintenance  Condition  and  Readiness  Reports.  This  category 
includes  a  minimum  of  four  types  of  data  sources: 

(1)  Report  of  Significant  Casualties. 

(2)  Force  Status  Reporting  System  (FORSTAT). 

(3)  Commanding  Officer's  Narrative  Reports. 

(4)  Department  8  O'clock  Reports. 

The  above  types  of  data  sources  may  be  examined  for  cross-checking 
purposes.  Particular  attention  will  be  given  to  reports  of  significant 
casualties  and  commanding  officer's  narrative  reports  as  potential  sources 
of  maintainability  problem  data. 

3.4  Safety  Hazard  Reports.  This  category  currently  includes  two  types 
of  data  sources: 

(1)  Serious  Safety  Deficiency  Reports. 

(2)  Forces  Afloat  Accident/Near  Accident  Reports. 

Both  of  these  types  of  reports  deal  with  significant  safety  problems  and, 
as  such,  may  describe  those  safety  problems  that  impact  maintenance  of 
equipment. 

3.5  Other  Non-MDS  Data  Sources.  Other  categories  of  non-MDS  data 
sources  exist.  At  the  present  time,  these  other  sources  appear  to  be 
potentially  less  fruitful  than  those  described.  However,  they  will  be 
sampled  to  determine  if  significant  information  may  be  found  by  accessing 
them. 

Table  E-l  describes  sample  non-MDS  data  sources  in  context  categories. 
These  tables  are  adapted  from  the  three-volume  study  entitled  "Ship 
Maintenance  Data  Sources  and  Systems:  An  Interim  Review,"  prepared  in 
August  1977  for  the  Ship  Support  Improvement  Project  of  the  Naval  Sea 
Systems  Command. 


Manufacturer  and  model . 

Job  Sequence  Number  (JSN)  identified. 
AN  designator,  manufacturer. 


INSPECTION  AND  TEST  REPORTS 


Notes:  1.  Mark/mod. 

2.  Naval  Ammunitions  Logistics  Code  (NALC) 


SUMMARY  MAINTENANCE  CONDITION  AND  READINESS  REPORTS 


CASREPT  readiness  rating  code  (c-rating);  see  Naval  Warfare  Publica 


SAFETY  HAZARD  REPORTS 


4. 


Accessibility  of  Data  Sources 


The  central  location  of  MDS  data,  from  which  most  maintenance  data  can  be 
accessed,  is  the  Navy  Maintenance  Support  Office  (NAMSO)  in  Mechanicsburg, 
Pennsylvania.  NAMSO  maintains  the  Central  Data  Bank  and  prepared  reports 
based  on  this  data.  The  accessible  data  consists,  in  the  main,  of  material 
from  OPNAV  4790/2  series,  NAVSUP  1250,  DD  1348,  and  some  INSU&V  and  Safety 
Reports  recorded  on  4790  forms. 

Non-MDS  sources  are  generally  manual  and  are  not  held  in  a  central 
location.  They  may  be  accessed  from  individual  ships,  shipyards,  and  test 
and  evaluation  offices.  Since  there  is  no  central  location  for  all  these 
data,  accessibility  will  present  a  logistics  problem  that  will  require 
sampling  procedures. 

The  Casualty  Reports  (CASREPS),  from  which  the  data  of  critical  equipment 
failures  and  the  effect  of  these  failures  on  the  capabilities  of  the 
reporting  Navy  ship  may  be  assessed,  can  be  obtained  from  Navy  Ships  Parts 
Control  Center  (SPCC),  Mechanicsburg,  PA.  The  CASREP  reports  can  be  used 
to  assist  in  identifying  problem  equipments,  support  deficiencies,  and 
maintenance  difficulties,  etc. 

5.  Summary 

A  large  volume  of  maintenance  data  currently  exists  and  is  continuously 
being  collected  by  the  U.S.  Navy.  It  is  divided  into  two  general 
categories:  (1)  MDS  data  that  is  available  in  a  computerized  version  from 
a  central  location;  (2)  Non-MDS  data  that  is  available  in  manual  format  and 
must  be  accessed  from  individual  ships  and  maintenance  facilities. 
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Most  of  the  maintenance  information  available  is  not  fully  useful  to  this 
program.  That  maintenance  information  that  is  likely  to  be  useful  is: 

(1)  maintenance  jobs  and  tasks;  (2)  equipment  to  which  jobs  and  tasks 
apply;  (3)  real-time  man  hours,  and  troubleshooting  time  required  for  each 
maintenance  job;  (4)  priority  of  each  management  job;  and  (5)  rating  of 
personnel  scheduled  for  each  type  of  maintenance  job.  There  may  be  data  on 
maintainability  problems  for  pieces  of  equipment  and/or  maintenance  jobs, 
but  this  is  uncertain.  If  there  are  such  data,  it  will  probably  be  spotty 
and  incomplete,  at  best. 
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Appendix  F 

Sources  of  Operator  Workload 


It  is  generally  agreed  that  there  are  six  clearly  identifiable  reasons  for 
unmanageable  operator/maintainer  workload.  These  are: 

•  Perceptual  saturation 

•  Need  to  perform  tasks  concurrently 

•  Timeline  compression 

•  Operator  physiological  limitations 

•  Excessive  small  scale,  routine  operations 

•  Operator  cognitive  time-bandwidth  barriers 

•  Indiscriminate  automation 

Each  of  these  problems  is  discussed  in  the  following  paragraphs. 

Perceptual  Saturation 

This  phenomenon  manifests  itself  when  a  number  of  critical  events  occur 
simultaneously,  with  the  result  that  the  operator  is  unable  to  cope  with 
the  situation.  For  example,  when  several  events  have  occurred  and  all 
demand  perceptual  attention  in  casualty  control,  the  serial  processing 
operator  easily  loses  track  of  the  threats  and  control  over  his  reactions. 

Concurrent  Task  Performance 


Operators  frequently  must  perform  several  tasks  concurrently  such  as 
maintaining  visual  awareness  out  of  the  control  room  while  monitoring 
critical  displays  with  the  control /monitor  Instruments.  Combined  with 
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these  visual  tasks  may  be  the  simultaneous  need  for  voice  contact  and 
communication  with  the  maintenance  team.  This  situation  causes  conflicting 
demands  on  his  sensors  and  supporting  control  processing  resources. 


Timeline  Compression 

Since  casualty  control  procedures  are  highly  time-stressed,  there  is  very 
little  time  available  to  the  operator  to  exercise  judgement  and  take 
action.  In  a  typical  encounter  of  a  major  main  reduction  gear  lube  oil 
leak,  the  operator  has  a  whole  host  of  tasks  to  complete  from 
detection/confirmation  of  the  event,  location  of  the  causes,  system  status, 
and  appropriate  procedures/actions.  If  for  mission  phase,  plant  status  or 
other  reasons  the  time  available  is  very  short,  the  same  number  of  tasks 
still  must  be  performed  but  in  a  much  compressed  time-scale. 

Operator  Physiological  Limits 

Humans  are  limited  in  the  rate  at  which  they  can  perform  manual  tasks. 
This  characteristic  is  referred  to  here  as  operator  motor  limits  even 
though  portions  of  this  limit  have  been  identified  as  cognitive.  An 
operator  typically  needs  on  the  order  of  one-half  second  to  make  a  simple 
control  adjustment.  Consequently,  he  is  incapable  of  manual  execution 
requiring  much  more  than  two  manually  executed  corrections  per  second. 
Where  this  situation  occurs,  some  form  of  enhancement  or  partial  automation 
is  not  just  desirable  but  mandatory. 

Excessive  Small  Scale  Tasks 


Operations  requiring  several  small  steps  can  significantly  increase 
operator  workload.  Such  tasks  are  typically  time-consuming.  In  performing 
these  tasks,  operators  are  prone  to  making  errors  of  omission,  i.e., 
skipping  steps.  In  addition,  such  tasks  impose  a  formidable  memory  burden 
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on  operators  that  can  adversely  impact  performance  on  other  tasks. 


Operator  Cognitive  Time-Bandwidth  Limits 

Humans  have  a  finite  and  relatively  small  limit  on  the  number  of  different 
symbols  that  can  be  retained  and  correlated  in  primary  memory.  In  the 
casualty/contingency  handling  tasks,  recognizing  particular  casualty 
generally  requires  consideration  of  a  number  of  different  but  related 
symptoms  or  factors.  Two  items  can  cause  overload.  First,  if  the  number 
of  factors  needed  for  consideration  in  the  recognition  or  multiple-source 
casualty  exceeds  the  humans  limit,  the  diagnosis  may  be  flawed.  Second,  if 
the  time  available  to  recall  or  formulate  handling  procedures  is  less  than 
the  human's  ability  to  formulate  a  single  set,  the  entire  process  breaks 
down  -  usually  catastrophically. 

Indiscriminate  Automati on 


Automation  can  be  a  mixed  blessing.  If  introduced  without  proper  prior 
analysis  of  tasks  it  can  produce  the  opposite  effect,  i.e.,  increase  rather 
than  decrease  operator  workload.  In  fact,  there  are  at  least  seven 
alternatives  to  automation  that  can  enhance  the  combined  performance  of 
operator  and  system.  These  are:  (1)  improving  human  engineering  in 
cockpit  design,  (2)  improving  procedures,  (3)  training  operators,  (4) 
selecting  operators,  (b)  changing  crew  composition,  (6)  improving 
motivation,  (7)  prescribing  methods  to  cope  with  stress. 
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